# Permission Sets for Configurations and Integrations {% hint style="info" %} **Early Access Feature**: Access Controls require enablement by Veza support. Contact your Veza support team to enable this feature for your tenant. When enabled, this feature changes the default access model for Access Reviews, Lifecycle Management, and Integration management across your entire tenant. {% endhint %} ## Overview Access Controls (also referred to as the **Limit Access** feature) add a permission-set-based RBAC layer on top of the existing Veza role system. When enabled, access to Access Review Configurations, Lifecycle Management Access Profiles, and Integrations shifts from role-based defaults to explicit per-resource assignments. Administrators always retain full access to all resources regardless of assignments. [Access Reviews Admins](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md) retain full access to all Access Review Configurations and Reviews. Two feature flags control this feature independently: * `AWF_ENABLE_PERMISSION_SETS` — Controls access restrictions on Access Review Configurations and Access Profile creation * `INTEG_PROVIDERS_RBAC_PERMISSION_SETS` — Controls per-integration permission assignments Each flag can be enabled separately. When a flag is enabled, the corresponding resources shift to a **deny-by-default** access model where users must be explicitly granted access. Users automatically receive permissions for resources they create. | Area | Default (Feature Off) | With Access Controls | | ---------------------------- | ---------------------------------------------------- | -------------------------------------------------------------------------- | | Access Review Configurations | All Operators can view and manage all configurations | Only assigned users and groups can view and manage specific configurations | | Access Profiles | Only Administrators can create profiles | Operators with Creator permissions can create profiles | | Integrations | Role permissions govern access | Per-integration assignments control create, read, update, delete | {% hint style="warning" %} **Enablement changes access immediately.** When a flag is enabled on a tenant with existing resources, Veza runs a migration that assigns Owner permissions to the original creators of those resources. Other users — including Operators — lose access to resources they did not create, unless they are Administrators or have been explicitly granted access. Coordinate with your team before enabling Access Controls to ensure the necessary permission assignments are in place. {% endhint %} ## Access Review Configuration Control Control which users can view and manage specific Access Review Configurations. When this feature is enabled, access to configurations is restricted based on explicit assignments. **How Access Control Works:** Access Reviews uses a two-level access model: 1. **Visibility**: Users must be explicitly added to a configuration's access list to see it. Without access, the configuration and its reviews are not visible. 2. **Capabilities**: What users can do with accessible configurations is determined by their Veza role. Adding a user to the access list grants visibility; their role determines their actions. **Who Has Access:** * **Administrators and** [**Access Reviews Admins**](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md): Always have full access to all configurations (no assignment required) * **Configuration Creators**: Automatically receive access to configurations they create * **Assigned Users**: Users and groups explicitly added to a configuration's access list **Capabilities by Role:** When assigned to a configuration, users can perform actions based on their Veza role: | Role | Capabilities on Assigned Configurations | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Operator | Full management: create reviews, edit settings, act on all results | | Access Reviews Monitor | Create and manage reviews, act on results, view progress | | Watcher | View-only: see configuration and review details, cannot make changes. Can act on rows where [assigned as a reviewer](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/assign-reviewers.md). | | Reassigner | View details and reassign reviewers in active reviews | | Access Reviewer | View and act on assigned results only | **Configuration-to-Review Inheritance:** Access permissions are set at the Configuration level and automatically cascade to all Reviews created from that Configuration. Access cannot be granted at the individual Review level. * Users without Configuration access **cannot view or act on Reviews** created from it * Granting Configuration access enables access to **all existing and future Reviews** for that Configuration * Revoking Configuration access removes access to all Reviews for that Configuration {% hint style="info" %} If an Operator cannot view or act on review results, they need to be added to the parent Configuration's access list. Contact an Administrator to grant access. {% endhint %} See [Create a Configuration](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/review-configuration.md) for step-by-step instructions on managing configuration access during creation. ### Example: Combining observation and review across configurations Access Controls can enable workflows where a single user observes some reviews while actively reviewing others. For example: 1. A user is assigned the **Watcher** role on the root team 2. Access Controls are enabled, and the user is added to the access list for two configurations: **Application A** and **Application B** 3. The user can view both configurations and their reviews (Watcher visibility) 4. An operator [assigns the user as a reviewer](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/assign-reviewers.md) on specific rows in the Application B review 5. The user can now act on their assigned rows in Application B (approve, reject, sign off) while remaining a read-only observer on Application A This works because any user assigned as a reviewer on specific rows receives reviewer permissions for those rows, regardless of their platform role. See [User Roles and Permissions](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md) for details on role capabilities and the assigned reviewer mechanism. ## Access Profile Creation Permissions With Access Controls enabled, Administrators can delegate Access Profile creation to specific Operators and Groups. Users granted Creator permissions can create new Access Profiles and automatically become the owner of profiles they create. Owners can edit their own profiles but cannot modify profiles created by others. Users must have the **Operator** role to benefit from Creator permissions. Permissions are managed via **Lifecycle Management > Settings > Manage Access Profile Creation Permissions**. See [Manage Access Profile Creation Permissions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/manage-access-profile-permissions.md) for step-by-step instructions. ## Integration Management Permissions With Access Controls enabled, each integration is identified by a unique RBAC ID (format: `data_providers.`). Administrators assign granular permissions (Create, Read, Update, Delete) to users or groups on individual integrations using built-in permission sets via the API. Users who create an integration automatically receive Owner permissions on it. Team-based restrictions still apply — non-root team members can only manage integrations within their team's scope. Integration-level Access Controls add an additional restriction layer on top of team and role-based access. {% hint style="info" %} Integration permission management is currently API-only. A UI for per-integration permissions is not yet available. {% endhint %} See [Manage Integration Permissions](/4yItIzMvkpAvMVFAamTf/integrations/configuration/manage-integration-permissions.md) for API instructions and permission set details. {% hint style="warning" %} **Important**: If you remove your own access to a resource, you will lose the ability to manage it. Only Administrators can restore access in this scenario. {% endhint %} ## See Also * [User Roles and Permissions](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md) - Understanding Veza roles and their capabilities * [Team Management](/4yItIzMvkpAvMVFAamTf/administration/administration/users/teams.md) - Organizing users and controlling integration scope * [Create a Configuration](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/review-configuration.md) - Managing Access Review Configuration access * [Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md) - Understanding Access Profiles in Lifecycle Management * [Configuring Integrations](/4yItIzMvkpAvMVFAamTf/integrations/configuration.md) - Integration configuration overview --- # 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/administration/administration/access-controls.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.