In dFlow, a tenant is an Organisation

billing, Applications, Worker Nodes, integrations, SSH keys, security groups, and team members all belong to exactly one Organisation.

Membership

A single user account can belong to more than one Organisation. Each membership has its own role. Switching the active Organisation in the dashboard changes which tenant’s data and permissions apply.

There is no cross-tenant sharing of resources inside the product: another Organisation’s servers or applications are invisible unless you are a member there too.

Roles live inside the Organisation

Roles are defined per Organisation. Role Management on Workspace → Team lists those roles and their permission matrix.

• Admin is the built-in full-access role (see Roles and permissions).
• Additional preset roles (for example a developer-oriented template) may exist on new workspaces; treat the UI as authoritative for what your tenant currently has.

What RBAC does not replace

• SSH keys and security groups still need correct configuration on the Security page; RBAC only controls who may edit them.
• Cloud provider credentials remain sensitive: least-privilege IAM and key rotation are your responsibility even when cloudProviderAccounts permissions allow linking accounts.
• Self-hosted control plane operators may have infrastructure access (SSH, Compose, database) that is outside dashboard RBAC.

Plan and feature gates

On dFlow Cloud, some actions (for example adding team members or certain compute flows) may be blocked by subscription or usage limits even when RBAC would otherwise allow them. The UI usually surfaces that as a billing or upgrade message, not as a permission matrix error.

Related

• Organisations and tenants
• Invites and team members
• Security overview