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:
An access review is configured for all Okta Users with membership in the
Marketing TeamOkta Group.The configuration has Revoke access of rejected row on sign-off enabled. This requires an Okta integration configured for provisioning.
A reviewer identifies that Jane Doe, who recently transferred to Sales, still has membership in the
Marketing Teamgroup.The reviewer selects Jane Doe's membership row and chooses Reject.
When the reviewer signs off, auto-revocation sends an instruction to Okta and removes Jane Doe from the
Marketing Teamgroup.
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:
Access Reviews Advanced is enabled for your tenant.
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.
Enable Usage for Provisioning is turned on for the target integration.
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
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
Last updated
Was this helpful?