# Auto-Revocation 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. ## 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 | | Custom Application (OAA) | User (custom type) | Group, Role | | 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 | ## 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: 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: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/auto-revocation.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.