Manage Integration Permissions

How to control who can create, update, and delete specific integrations.

Overview

By default, users with the Integrations Manager or Integration Owner role can manage any integration. When the INTEG_PROVIDERS_RBAC_PERMISSION_SETS feature flag is enabled, Veza adds a per-integration permission layer: each integration is identified by a unique RBAC ID, and administrators assign permission sets (Owner, Maintainer, Viewer, Creator) to control which users and groups can create, read, update, or delete specific integrations.

Integration permission management is currently API-only via the Permission Set Service API (/api/private/permission_set_policies). A UI for managing per-integration permissions is not yet available.

Early Access Feature: This feature requires enablement by Veza support. Contact your Veza support team to enable the INTEG_PROVIDERS_RBAC_PERMISSION_SETS flag for your tenant.

Before you start

Before managing integration permissions, ensure:

• You have the Administrator role on the root team

• Access Controls feature is enabled on your tenant (contact Veza support if needed)

• The integrations you want to control are already configured

• You've identified which users or groups need integration management capabilities

Team Restrictions Still Apply: Even with integration permissions, non-root team members can only manage integrations within their team's scope. Access Controls add an additional layer of restriction on top of team-based access control.

Permission sets and permission types

Permissions are assigned using built-in permission sets. These permission set IDs are constant across all Veza tenants:

Permission Set	ID	Permissions
Owner	c345007c-244a-4606-b2e2-53f4f85e0ac0	Create, Read, Update, Delete
Maintainer	85b413c0-db25-42e9-b4d7-ef935759b188	Read, Update
Viewer	3f1af6de-dc60-4fdb-90ed-5c2493b8f767	Read
Creator	38f00b6e-695c-449d-96b9-3a72aeb7f3fd	Create

To list all available permission sets on your tenant, call GET /api/private/permission_sets.

Find an integration's RBAC ID

Every integration has an rbac_id field returned in its API response. The format is data_providers.<provider_id>.

To find the RBAC ID for a specific integration:

1. Call GET /api/v1/providers (or GET /api/v1/providers/{provider_id} for a specific integration).

2. Locate the rbac_id field in the response:

   {
     "name": "Production Salesforce",
     "provider_id": "019adb0f-de85-7802-8e55-b30ed104e2f5",
     "rbac_id": "data_providers.019adb0f-de85-7802-8e55-b30ed104e2f5"
   }

Wildcard patterns: Use data_providers.* as the RBAC ID to grant permissions on all integrations at once.

Grant integration management permissions

To assign permissions for managing a specific integration:

1. Find the integration's RBAC ID from the provider API response.

2. Make a POST request to /api/private/permission_set_policies:

   {
     "request": {
       "rbac_id": "data_providers.019adb0f-de85-7802-8e55-b30ed104e2f5",
       "type": "ADD",
       "principal": {
         "type": "USER",
         "id": "{user_or_group_id}"
       },
       "permission_set_id": "c345007c-244a-4606-b2e2-53f4f85e0ac0"
     }
   }

   Set the principal.type to USER or GROUP. Use the permission set ID from the permission sets table.

Result: The assigned user or group receives the specified permissions for the integration.

Automatic owner permissions

When a user creates an integration, they automatically receive Owner permissions (Create, Read, Update, Delete) on that integration. This automatic assignment works in combination with explicit permission grants made via the API.

Verify integration permissions

To confirm permission assignments using the API:

1. List all policies for an integration:

   GET /api/private/permission_set_policies?filter=rbac_id eq "data_providers.{provider_id}"

   Review the response to see all users and groups with permissions on this integration.

2. Check a specific user's permissions:

   GET /api/private/permission_sets/my_permissions/{rbac_id}

   Returns the current user's effective permissions on the specified resource.

3. Verify in the UI: Have the affected user log in and confirm:

   • The integration appears in their Integrations list (requires Read)

   • Edit/Configure buttons are visible (requires Update)

   • Delete option is available (requires Delete)

   • Users without permissions won't see the integration or will see it as read-only

Remove integration permissions

To revoke integration management permissions using the API:

1. List current permissions for the integration:

   GET /api/private/permission_set_policies?filter=rbac_id eq "{provider_rbac_id}"

2. Identify the permission policy ID for the user or group to remove.

3. Make a DELETE request:

   DELETE /api/private/permission_set_policies/{policy_id}

   Alternatively, use the POST endpoint with "type": "REMOVE":

   {
     "request": {
       "rbac_id": "{provider_rbac_id}",
       "type": "REMOVE",
       "principal": {
         "type": "USER",
         "id": "{user_id}"
       },
       "permission_set_id": "{permission_set_id}"
     }
   }

Result: The user or group loses management access to the integration. They may retain read-only access depending on their role and team assignments.

Caution: Removing permissions from an integration owner or the user who created the integration may create management gaps. Ensure another user has the necessary permissions before revoking access.

Permission layers

When Access Controls are enabled, Veza evaluates multiple independent layers before granting access to an integration. A user must satisfy all applicable layers:

• Role Permissions: The user's Veza role must include the base permission for the action. Integration create, update, and delete operations require the Integrations Manager (provider_manager) or Integration Owner (integration_owner) role. The Operator role can view integrations but cannot create, modify, or delete them. If the user's role grants full access (e.g., Administrator), the remaining checks are bypassed.

• Team Scope: Users can only access integrations assigned to their team. The default team used by Administrators has access to all integrations. Users on other teams can only see and manage integrations explicitly assigned to their team.

• Permission Set Assignment: The user must have an explicit permission set (Owner, Maintainer, Viewer, or Creator) on the specific integration — either through direct assignment, group membership, or automatic ownership.

For example, when an Integrations Manager on the "AWS Production" team wants to update an integration, Veza will check:

1. Does the Integrations Manager role include update permissions? Yes.

2. Is this integration assigned to the "AWS Production" team? If no, the integration is not visible.

3. Does this user have Owner or Maintainer permissions on this specific integration? If no, access denied. If yes, update succeeds.

Administrators bypass team scope and permission set restrictions, retaining full access to all integrations.

See also

• Permission Sets for Configurations and Integrations - Overview of the permission sets system

• Configuring Integrations - General integration configuration guidance

• Team Management - Using teams to control integration scope

• User Roles and Permissions - Understanding Veza roles

• Integration Owner role - Automatic ownership permissions