> 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-reviews/configuration/auto-revocation.md). # Auto-Revocation Automatically remove user access when a reviewer rejects and signs off a row during an access review. Auto-revocation automatically removes a user's access when a reviewer rejects and signs off a row during an access review, without the need for webhooks or custom integrations to facilitate access removal. On sign-off of a rejected row, auto-revocation triggers and removes the user from the target entitlement — such as a group, role, permission set, or license. This feature is available with **Access Reviews Advanced** and is limited to applications and entity types with provisioning and deprovisioning support enabled. ## Example use case Consider a **User to Group** access review targeting the `Marketing Team` group in Okta: 1. An access review is configured for all Okta Users with membership in the `Marketing Team` Okta Group. 2. The configuration has **Revoke access of rejected row on sign-off** enabled. This requires an Okta integration configured for provisioning. 3. A reviewer identifies that Jane Doe, who recently transferred to Sales, still has membership in the `Marketing Team` group. 4. The reviewer selects Jane Doe's membership row and chooses **Reject**. 5. When the reviewer signs off, auto-revocation sends an instruction to Okta and removes Jane Doe from the `Marketing Team` group. Jane Doe's access is revoked immediately on sign-off, with no manual admin intervention or follow-up ticket required. ## Enabling auto-revocation Open a review configuration, go to the **Veza Actions** section, and check **Revoke access of rejected row on sign-off**. ## Requirements The **Revoke access of rejected row on sign-off** checkbox only appears when all of the following conditions are met: 1. **Access Reviews Advanced** is enabled for your tenant. 2. The review query selects a user as the source entity type. The destination or summary entity type — such as a role or group — must be supported for provisioning and deprovisioning. 3. **Enable usage for Provisioning** is turned on for the target integration. 4. The integration is configured with sufficient permissions to manage relationships for the entity types in the query scope. Enabling provisioning creates a dedicated integration datasource that grants permission to remove relationships. If provisioning is not enabled for an integration, the checkbox will not appear even if the integration is otherwise active and connected. Provisioning capability is necessary but not sufficient. Auto-revocation also requires that the integration's revoke action recognizes the entity types in the review query. See [Supported integrations](#supported-integrations) for the current list. ## Supported integrations | Integration | Source | Removable entitlements | | ----------------------- | ---------------------- | --------------------------------------------------------------- | | Active Directory | Active Directory User | Active Directory Group | | Atlassian Cloud | Atlassian Cloud User | Atlassian Cloud Admin Group | | AWS IAM Identity Center | AWS SSO User | AWS SSO Group | | Azure AD | Azure AD User | Group, Role, Distribution Group, License | | GitHub | GitHub User | GitHub Organization, GitHub Team | | Google Workspace | Google Workspace User | Google Workspace Group | | MySQL | MySQL User | MySQL Role | | Okta | Okta User | Okta Group | | Oracle Database | Oracle DB User | Oracle DB Role | | Oracle Fusion Cloud | Oracle Fusion User | Oracle Role | | PagerDuty | PagerDuty User | PagerDuty Team | | PostgreSQL | PostgreSQL User | PostgreSQL Group | | Salesforce | Salesforce User | Group, Permission Set, Permission Set Group, Profile, User Role | | SCIM | SCIM User | SCIM Group | | Snowflake | Snowflake User | Snowflake Role | | Splunk Enterprise | Splunk Enterprise User | Splunk Enterprise Role | | Veza | Veza User | Role Binding, Access Profile, Group | | Workday | Workday Worker | Workday Security Group | ### Custom applications built with OAA Auto-revocation is not currently supported for custom applications integrated through the Open Authorization API. This applies to all OAA-based integrations, including those configured with stored procedures and **Enable usage for Provisioning** turned on. The revoke path does not yet recognize provider-prefixed entity types such as `OAA..User` and `OAA..Role`, so the **Revoke access of rejected row on sign-off** checkbox does not appear for these integrations. For OAA custom applications that need to remove access on rejection, use a webhook-based [Veza Action](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/veza-actions.md) instead. ## Scope requirements * The source entity type must be a user identity. The destination must be a role, group, permission set, or license in the same application as the source. * Auto-revocation can remove access to an intermediate entity in a relationship path. For example, a review querying Active Directory User → AD Group → SQL Server Database paths can reject the User-to-Database relationship, revoking the intermediate group membership that grants it. * Cross-application scenarios are not supported. A review of Okta users to Snowflake databases will not show the auto-revocation option. * Source-only reviews (no destination entity) are not supported. ## See also * [Verify Remediations](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/verify-remediations.md) — after auto-revocation removes access, use Verify Remediations to automatically confirm the access is gone and mark rows as Fixed * [Veza Actions for Access Reviews](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/veza-actions.md) * [Access Reviews configuration](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration.md) * [LCM target applications](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/integrations.md) --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/auto-revocation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.