Skip to content

Platform vs Tenant Admin

DIBOP separates administration into two distinct scopes: Platform Admin and Tenant Admin (Enterprise Admin). This separation ensures security, data isolation, and clear ownership of responsibilities.

Why Two Admin Roles?

DIBOP is a multi-tenant platform. Multiple enterprises share the same platform infrastructure, but each enterprise's data is completely isolated. The two admin roles reflect this architecture:

  • The Platform Admin manages the shared infrastructure
  • The Tenant Admin (Enterprise Admin) manages their own enterprise's integrations

This separation exists for three reasons:

  1. Security: Platform administrators should not have access to enterprise-specific credentials or data
  2. Isolation: Changes made by one enterprise must not affect another
  3. Ownership: Each enterprise is responsible for its own integrations and data

What the Platform Admin Controls

The Platform Admin role is responsible for the shared resources that all enterprises use:

Connector Catalogue

Responsibility Description
Create connectors Build new connector templates using the Connector SDK
Publish connectors Make connectors available to all enterprises
Unpublish connectors Remove connectors from the catalogue (does not affect existing connections)
Manage versions Update connector templates with bug fixes or new operations

Quotas and Limits

Responsibility Description
API call quotas Set per-enterprise limits on API calls per billing period
Execution limits Set per-enterprise limits on orchestration executions
Storage quotas Set per-enterprise limits on data retention storage
Rate limits Configure rate limits to protect the platform and external systems

Platform Health

Responsibility Description
Cross-tenant health Monitor overall platform health across all enterprises
System availability Track whether external systems are reachable
Infrastructure metrics Monitor platform resource usage (compute, storage, network)

Gateway Products

Responsibility Description
API tiers Define API product tiers (free, standard, premium)
Subscription management Manage which enterprises have access to which tiers
Rate limiting Configure per-tier rate limits

Enterprise Provisioning

Responsibility Description
Create enterprises Set up new enterprise accounts
Configure defaults Set default retention periods, quotas, and settings for new enterprises
Manage SSO Configure identity provider integrations

What the Tenant Admin Controls

The Tenant Admin (Enterprise Admin) role manages everything within their own enterprise:

Connections

Responsibility Description
Connect systems Browse the catalogue and configure connections
Manage credentials Enter, rotate, and validate credentials
Monitor connections Track connection health and troubleshoot issues

Orchestrations

Responsibility Description
Build orchestrations Create workflows using the Visual Builder, AI Composer, or manual configuration
Manage lifecycle Activate, pause, and archive orchestrations
Execute and test Run orchestrations and review results
Monitor Track execution success, SLA compliance, and alerts

Users and Security

Responsibility Description
User management Add, edit, and remove users within the enterprise
Role assignment Assign roles to users
Security settings Configure session timeouts, 2FA requirements, and password policies

Data and Monitoring

Responsibility Description
Canonical data View and manage canonical data records
Field mappings Configure how connector fields map to the CDM
Alerts Set up and manage alert rules
Retention Configure data retention periods (within platform-set limits)

What Each Role Can See

Platform Admin's View

The Platform Admin sees:

  • The full connector catalogue (including drafts)
  • Cross-enterprise health metrics (aggregate, no per-enterprise detail)
  • Platform configuration pages
  • Enterprise provisioning tools

The Platform Admin does not see:

  • Enterprise-specific orchestrations or their execution data
  • Enterprise credentials (even in encrypted form)
  • Enterprise-specific API call logs or payloads
  • Enterprise user activity

Tenant Admin's View

The Tenant Admin sees:

  • Their own enterprise's connections and orchestrations
  • Their own execution logs, API call logs, and metrics
  • Their own users and settings
  • The published connector catalogue

The Tenant Admin does not see:

  • Other enterprises' data (connections, orchestrations, users, logs)
  • Draft connectors in the catalogue
  • Platform-level configuration (quotas are visible but not editable)
  • Cross-enterprise health metrics

Data Boundary

The data boundary between platform and tenant is strict:

┌──────────────────────────────────────────────────┐
│                 PLATFORM LEVEL                    │
│  Connector templates, quotas, gateway products    │
│  (Platform Admin scope)                          │
├──────────────────────────────────────────────────┤
│  Enterprise A      │  Enterprise B      │  ...   │
│  ─────────────     │  ─────────────     │        │
│  Connections       │  Connections       │        │
│  Credentials       │  Credentials       │        │
│  Orchestrations    │  Orchestrations    │        │
│  Execution logs    │  Execution logs    │        │
│  Users             │  Users             │        │
│  Settings          │  Settings          │        │
│  (Tenant Admin)    │  (Tenant Admin)    │        │
└──────────────────────────────────────────────────┘

No data crosses the enterprise boundary. Even if the same person is both a Platform Admin and a Tenant Admin for a specific enterprise, they access each scope through separate interfaces.

Overlap: Connector SDK Access

In some configurations, the Platform Admin may grant Tenant Admins access to the Connector SDK. This allows enterprises to build their own connectors for systems not in the catalogue.

When a Tenant Admin builds a connector:

  • The connector is enterprise-scoped by default (only visible to their enterprise)
  • The Platform Admin can optionally promote it to the shared catalogue
  • Enterprise-scoped connectors follow the same security and isolation rules as other enterprise data

Why This Matters

For Security

The separation ensures that a breach in one enterprise does not expose another enterprise's data. Platform Admins cannot exfiltrate enterprise credentials, and enterprises cannot access each other's data.

For Compliance

Many enterprises have regulatory requirements about who can access their data. The platform-vs-tenant separation provides a clear boundary that maps to compliance requirements.

For Operations

Each enterprise can operate independently: creating connections, building orchestrations, and managing users without waiting for platform-level changes. The Platform Admin only needs to be involved for catalogue updates and quota adjustments.

Next Steps