Skip to content

Roles & Permissions

DIBOP uses role-based access control (RBAC) to determine what each user can see and do. Roles are assigned at the enterprise level and control access to features, data, and administrative functions.

Built-In Roles

DIBOP provides three built-in roles:

Platform Admin

The Platform Admin role is for users who manage the DIBOP platform itself. This role exists outside the scope of any single enterprise.

Platform Admins can:

  • Manage the connector catalogue (create, edit, publish, unpublish connectors)
  • Configure platform-wide settings (quotas, rate limits, retention defaults)
  • View cross-enterprise health metrics
  • Manage gateway products and API tiers
  • Create and manage enterprises

Platform Admins cannot:

  • View enterprise-specific credentials
  • Access enterprise-specific data (orchestration payloads, customer records)
  • Execute orchestrations on behalf of an enterprise

Separate Concern

Platform Admin is a separate concern from Enterprise Admin. A person can hold both roles, but they serve different purposes. See Platform vs Tenant Admin for a detailed comparison.

Enterprise Admin

The Enterprise Admin role (also called Tenant Admin) is for users who manage integrations and operations within their enterprise.

Enterprise Admins can:

Category Permissions
Connections Create, configure, test, activate, deactivate, and delete connections
Credentials Enter and rotate credentials for connections
Orchestrations Create, edit, activate, pause, archive, and delete orchestrations
Execution Run orchestrations, view execution logs and traces
Monitoring View all dashboards, API call logs, and metrics
Alerts Create, edit, and delete alert rules; silence alerts
Users Add, edit, deactivate, and delete users within the enterprise
Settings Configure enterprise settings (branding, retention, notifications)
Data Model View canonical data model, manage field mappings
Connector SDK Build custom connectors (if platform admin has enabled this)

Viewer

The Viewer role is for users who need to see what is happening but should not make changes.

Viewers can:

Category Permissions
Connections View connection list and status (cannot modify)
Orchestrations View orchestration list and configuration (cannot modify)
Execution View execution logs and traces (cannot trigger executions)
Monitoring View all dashboards, API call logs, and metrics
Alerts View alert rules and history (cannot create or modify)
Data Model View canonical data model and field mappings

Viewers cannot:

  • Create, edit, or delete any resources
  • Configure credentials
  • Manage users
  • Change settings
  • Execute orchestrations

Permission Matrix

Action Platform Admin Enterprise Admin Viewer
View connections Per-enterprise Yes Yes
Create connections No Yes No
Manage credentials No Yes No
View orchestrations Per-enterprise Yes Yes
Create orchestrations No Yes No
Execute orchestrations No Yes No
View execution logs Per-enterprise Yes Yes
View API call logs Per-enterprise Yes Yes
View dashboards Cross-enterprise Yes Yes
Create alert rules No Yes No
Manage users Enterprise provisioning Yes No
Enterprise settings No Yes No
Connector catalogue Yes View only View only
Connector SDK Yes If enabled No
Platform config Yes No No

Assigning Roles

At User Creation

When you add a user, you select their role from the dropdown. The role is effective immediately.

Changing a Role

  1. Navigate to SETTINGS > User Management
  2. Click on the user
  3. Change the Role dropdown
  4. Click Save

The new role takes effect immediately. If the user is currently signed in, their permissions update on their next page navigation.

Role on First Login (SSO)

When a user signs in via SSO for the first time:

  • If the identity provider includes a role claim, DIBOP uses it
  • If no role claim is present, the user is assigned the Viewer role by default
  • An Enterprise Admin can upgrade their role afterwards

Custom Roles

Coming Soon

Custom role creation is planned for a future release. Currently, the three built-in roles cover the most common access patterns.

If the built-in roles do not fit your needs, consider:

  • Assigning Viewer to users who should not make changes
  • Assigning Enterprise Admin to users who need to make changes
  • Controlling sensitive operations through process (e.g., requiring approval before production orchestration changes) rather than RBAC

Role Hierarchy

Roles form a simple hierarchy:

Platform Admin
     │
Enterprise Admin
     │
   Viewer

Higher roles include all permissions of lower roles (within the same enterprise scope). An Enterprise Admin can do everything a Viewer can do, plus more.

Platform Admin is a special case -- it has broad platform-level access but deliberately restricted enterprise-level access to enforce data isolation.

Audit Trail

All role assignments and changes are recorded in the audit log:

  • Who assigned the role
  • When the assignment was made
  • What the previous role was (for changes)

View the audit log in Enterprise Settings.

Best Practices

  1. Default to Viewer: Assign Viewer to new users until they need elevated access
  2. Limit Enterprise Admins: Only users who actively manage integrations should have this role
  3. Review roles quarterly: People change responsibilities; roles should change with them
  4. Use SSO role mapping: If your identity provider supports role claims, configure it to auto-assign roles

Next Steps