> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-request/request-history.md). # Access request history Review the recorded actions, approvals, and state changes for a single access request in Access Hub, and review requests across the tenant from the Lifecycle Management Access Requests table. Every access request carries a record of the actions, approvals, and state changes that moved it from submission through provisioning. Review the history for a single request in Access Hub, review requests across the tenant from the **Access Requests** table in Lifecycle Management, or retrieve request records through the Access AuthZ API. {% hint style="info" %} This page covers the history of access requests. For provisioning jobs, tasks, and events across Lifecycle Management, including operations that no access request initiated, see [Provisioning Activity](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/getting-started/activity-log.md). {% endhint %} ## Overview The request history captures the actions, approvals, and state changes for an access request, so your organization has a record of how each request progressed from submission through provisioning. In Access Hub, users can access a detailed history for each access request. The request details provide information, including: * **Requester Identification**: Who initiated the access request. * **Approval/Rejection Authority**: Who was responsible for approving or rejecting the request. * **Action Timestamps**: When each action occurred, including the initial request, any approvals or rejections, and subsequent provisioning. * **Provided Justifications**: Why requesters claimed the access needed, as well as any reasons provided by approvers for their decisions. History entries are generated automatically as actions occur. Each entry is timestamped and attributed to the user or system that performed the action, and the history is not editable from Access Hub, so the recorded sequence of actions is available for later review. During security incidents or investigations, the request history is the audit record for forensic analysis, helping to establish how access was granted and what actions were taken. ### What the history records Each access request includes a record of all user actions (approvals, rejections, cancellations, information requests, re-requests, and revocations) and automated actions (auto-approval, expiration, and errors). Each entry includes the action type, who performed it, when it happened, the justification or message, and the states before and after. ### Who can see a request Most access to request history follows from a user's relationship to the request: users see the requests they created, the requests for their own access, the requests assigned to them for approval, and the requests they are watching. Managers also see the requests of their direct reports. | Relationship to the request | What the user can see | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | Requester | Requests they created | | Beneficiary | Requests for their own access | | Manager | Requests for their direct reports, one level down only. A manager does not see requests from further down the reporting chain. | | Approver | Requests currently assigned to them for approval | | Access Profile Owner | Requests routed to them for approval on a profile they own, through the Access Profile Owner approval step | | Watcher | Requests they are watching | Read-all access is different in kind: it is a platform role grant rather than a relationship to a particular request. The `admin` and `remediation_owner` roles hold read-all for access requests and see every request in the tenant, whether or not they are involved in one. The same scoping applies in Access Hub, in the Lifecycle Management **Access Requests** table, and through the API. ## Reviewing a single request To view request details and history: 1. Go to **Access Hub** > **Catalog** > **Requests** (or **Assigned Requests**). 2. Select a request to open it in the details sidebar. 3. In the sidebar, select **Details** to view full request details. The request details header shows key information at a glance: * **Status**: Current request state (color-coded) * **Request For**: The beneficiary * **Date Requested**: When the request was submitted * **Duration**: Access duration (permanent or time-limited with expiration) * **Request By**: Who submitted the request * **Needs Approval By**: Pending approvers (if applicable) * **Error Message**: The system message for the request. A populated message does not always mean the request failed. A request in Conflict Pending also carries one, explaining why the approval step could not be routed * **Rejection Reason**: Why the request was rejected (if applicable) * **ServiceNow Ticket**: Linked ITSM ticket ID and status (if applicable) Below the header, you can switch between tabs showing the chronological workflow and approval process, granular execution events for the request, the high-level actions performed to fulfill the request, and any specific entitlements granted or revoked by the request. ### History tab This tab shows changes to the request state in chronological order. You can check each column for more information: * **Created At**: Date and time of the action * **Created By**: User who performed the action * **Action**: Type of action (Approve, Reject, Cancel, Request More Information, Rerequest, Revoke Access) * **Message**: User-provided justification or system-generated message * **Current State**: Request state after this action * **Previous State**: Request state before this action For time-limited access, if an approver changes the requested access duration, the history indicates both the previous and new duration. The History tab also records automated system actions, such as auto-approval (when policy allows), JIT revocation (when access duration expires), and escalation (when an expiration policy escalates to additional approvers). Automated entries are marked as system-generated rather than attributed to a specific user. The history entries travel with the request itself rather than coming from a separate history log, so the History tab shows the same entries and the same columns wherever you open a request, in Access Hub or in the Lifecycle Management **Access Requests** table. ### Events tab Use this tab to see the technical details of how access was granted or revoked in target systems. You can filter to search by date range, success status, and event type. For event, columns indicate the: * **Event Type**: Type of operation (Add Relationship, Remove Relationship, and so on) * **Timestamp**: When the event occurred * **Success**: Whether the operation succeeded * **Identity**: The identity affected by the operation * **Entity Name**: The target entity * **Entitlement Entity**: The specific entitlement involved * **Message**: Additional details or error messages ### Access Plan tab This tab shows the provisioning actions performed to fulfill the request: the specific operations Veza executed (or will execute) in target systems. The table is titled **"Actions Performed"** and includes: * **Action**: The type of provisioning action and its name (for example, Manage Relationships, Sync Identities, Deprovision Identity, Create Email, Send REST Payload) * **Status**: Success or failure status for each action For approved requests, the Access Plan represents the execution plan that Veza generated to grant or revoke the requested access. For time-limited (JIT) access, a separate set of revocation actions executes when the duration expires. ### Entitlements tab The Entitlements tab shows the exact access that was requested or revoked, grouped by integration. * **App Name**: The target application * **Entitlement**: The specific entitlement (group, role, or permission) * **Action**: Actions available for the entitlement {% hint style="info" %} The Entitlements tab appears for requests that carry requested entitlements: Access Profile (Bundle) requests and application or catalog-derived requests with target entities. It is not shown for Catalog Definition requests that have no target entities. {% endhint %} ## Reviewing requests across the tenant The Admin Console lists access requests across the tenant in **Lifecycle Management** > **Access Requests**. Use this table when you need the history of many requests at once, rather than the detail of one: reporting on approval volume, finding the requests that granted a given entitlement, or locating a request by state or date. Each user sees the requests their role allows. The `admin` and `remediation_owner` roles see every request in the tenant, and other users see only the requests they are related to, as described in [Who can see a request](#who-can-see-a-request). The table has two tabs, **Pending** and **Completed**. A request is listed under **Pending** while it moves through approval and provisioning, and under **Completed** once it reaches a terminal state. There is no combined tab that lists both at once. Columns include: * **Name** and **Request Type**: what the request asks for, and which kind of request it is * **Request For** and **Request By**: the beneficiary and the user who submitted the request * **State**: the current request state * **Target Entities**: the entities the request grants or removes access to * **Comments**: the justification the requester provided * **Created At**, **Requested At**, and **Completed At**: when the request was created, submitted, and completed * **Revoke At**: when time-limited (JIT) access is revoked * **Message**: the system message for the request, such as the error reported by a failed provisioning action * **Access Request Id**: the request identifier, hidden by default and available from the column selector Select a request to open the same details view described in [Reviewing a single request](#reviewing-a-single-request), including the History, Events, Access Plan, and Entitlements tabs. You can filter the table by the same fields the columns show. For counts rather than individual requests, the **Access Requests** section of the [Lifecycle Management dashboard](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/getting-started/dashboard.md#access-requests) summarizes pending and recently completed requests by status. Use the dashboard to monitor volume, and this table to work through the requests behind it. ### Exporting the request table Export the **Access Requests** table to CSV to review requests outside the console or to attach them to a compliance report. The export applies the filters currently set on the table, and contains the table's columns plus the request identifier. It resolves display names for the requester, the assigned identity, the request type and state, and the access profile or data source behind each request, rather than raw identifiers. The export control is available only to roles that hold the Access Requests export permission. Administrators export the full table, and operators export the requests shown on their own table. ## API access to request records Request history can also be retrieved programmatically through the Access AuthZ API. Use `ListAccessRequests` with filters (by state, date range, assignee, or target) to query requests for compliance reporting and integration with external systems, `CountAccessRequests` to total the requests that match the same filters, and `GetAccessRequest` to retrieve one request together with its history entries. API callers are scoped the same way console users are: a caller without read-all receives only the requests they are related to. See [Access AuthZ API](/4yItIzMvkpAvMVFAamTf/developers/api/access-requests.md) for details. ## Related documentation * [Access Requests Overview](/4yItIzMvkpAvMVFAamTf/features/access-request.md): request lifecycle and state machine * [Provisioning Activity](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/getting-started/activity-log.md): provisioning jobs, tasks, and events across Lifecycle Management * [Lifecycle Management dashboard](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/getting-started/dashboard.md#access-requests): at-a-glance request counts by status * [ITSM Integration](/4yItIzMvkpAvMVFAamTf/features/access-request/configure-itsm-integration.md): ServiceNow ticket tracking linked to requests * [Access Request Notifications](/4yItIzMvkpAvMVFAamTf/features/access-request/notifications.md): notification channels for request events --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-request/request-history.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.