Action Allow List

Restrict which users can delete In Progress reviews or modify review due dates, independent of their assigned Veza role.

The Action Allow List restricts two sensitive review operations — deleting an In Progress review and modifying the due date of an In Progress review — to users granted roles that explicitly permit these operations. When the action allow list is enabled, only users on the list can perform these operations regardless of their assigned Veza role. When it is disabled, the existing role-based access controls apply unchanged.

Draft reviews are not affected by the allow list. The restriction only applies to reviews in the IN_PROGRESS state.

Users who are not on the allow list will not see the Delete or Edit Due Date controls in the review management interface. The controls are hidden (they do not appear in a disabled state). API requests to delete or modify the due date of In Progress reviews are also rejected with a permission error for users not on the allow list.

For full configuration guidance, see Action Allow List.

Role Requirements

Operation
Required Role

Enable or disable the allow list

admin

Add or remove users from the list

admin or access_reviews_admin

Check whether a user is permitted

admin or access_reviews_admin

Principals

Both users and groups can be added to the allow list. A user is permitted if their user ID is directly on the list, or if any Veza group they belong to is on the list.

Each principal is specified as an object with a type and id:

{"type": "USER", "id": "<veza-user-uuid>"}
{"type": "GROUP", "id": "<veza-group-uuid>"}

All IDs must be Veza internal UUIDs. Email addresses and usernames are not supported.

To look up a user's UUID:

  • Administration console: Go to Administration > Users, click the user's name, and copy the UUID from their profile page.

  • Users API: Use the Users and Teams API to list users and locate the id field in the response.

To look up a group's UUID:

  • Groups API: Use GET /api/private/groups to list groups and locate the id field for the target group. Use the filter query parameter to narrow by name (e.g., ?filter=name eq 'Your Group Name').

Allowed Actions

The allowed_action field controls which restricted operations the principal is permitted to perform. Specify one or both values:

Value
Description

DELETE_IN_PROGRESS_REVIEW

Permitted to delete an In Progress review

MODIFY_IN_PROGRESS_REVIEW_DUE_DATE

Permitted to modify the due date of an In Progress review

API Reference

Check Whether the Allow List Is Enabled

GET /api/private/workflows/access/settings/action_allowlist_enabled

Returns the current enabled state of the allow list.

Example:

Response:


Enable or Disable the Allow List

PUT /api/private/workflows/access/settings/action_allowlist_enabled

Enable or disable the allow list globally. When disabled, existing RBAC governs access to all review operations.

Request body:

Set value to true to enable or false to disable.

Example (enable):

Example (disable):


Add Principals to the Allow List

POST /api/private/workflows/access/action_allowlist

Add one or more users or groups to the allow list. A single request can include multiple principals of mixed types.

Request body:

Example (add a user for both actions):

Example (add a group):


Remove Principals from the Allow List

POST /api/private/workflows/access/action_allowlist:delete

Remove one or more principals from the allow list. Uses the same request shape as the add endpoint.

Request body:

Example:


List All Permitted Principals

GET /api/private/workflows/access/action_allowlist

Returns all users and groups currently on the allow list. Each entry represents one principal–action pair; a principal with two allowed actions appears as two separate entries.

Example:

Response:


Check Whether a User Is Permitted

GET /api/private/workflows/access/action_allowlist/{user_id}

Returns the resolved allowed actions for the specified user, including permissions inherited from group memberships. Pass a user UUID — passing a group UUID will return an empty allowed_actions array rather than an error.

Example:

Response:

Returns an empty array if the user is not on the list and belongs to no permitted groups.

Last updated

Was this helpful?