Roles and permissions

RBAC collections, CRUD flags, Admin vs custom roles, and how limits apply to Applications and Worker Nodes.

Written By Zoro

Last updated 3 days ago

dFlow enforces organisation-scoped RBAC

each member has one role per Organisation, and that role grants Create, Read, Update, and Delete on a fixed set of collections. Server actions check those flags (for example servers.update, team.read) before running.

Use Workspace → Team → Role Management to view or edit roles. The table columns match the internal collection names (see below).

Admin role

Admin is the full-access role. It is marked as an admin role in the product: the permission matrix is not edited cell-by-cell in the UI (checkboxes are disabled) and the role is treated as having full access.

The first user created for a new Organisation is typically linked to Admin. New tenants are also seeded with an additional Developer-style preset role you can change or delete as you refine access (exact names and defaults may evolve; use Role Management as source of truth).

Custom roles

You can add roles (for example Viewer, Contractor, Platform) and toggle Create / Read / Update / Delete per collection. Anyone with roles.create and roles.update can maintain the matrix.

Collections (permission rows)

Each row is one collection. Customer-facing meaning:

Collection (UI label)	What it gates
`projects`	Legacy Projects (still shown while accounts may run mixed legacy and Applications workflows).
`applications`	Applications (create, open, change, delete).
`environments`	Environments inside Applications.
`services`	Services (deploy, settings, delete, and related service operations).
`servers`	Worker Nodes and server lifecycle (add server, Dokku prep, monitoring tools, and similar).
`templates`	Templates (create, publish, deploy from template, and related).
`roles`	Role Management (who may define or edit roles).
`backups`	Backups actions tied to services and backup records.
`securityGroups`	Security → Security groups.
`sshKeys`	Security → SSH keys.
`cloudProviderAccounts`	Linked cloud provider accounts (for example AWS keys used for EC2 and security groups).
`dockerRegistries`	Docker registry integrations.
`gitProviders`	Git provider connections (GitHub App, tokens, and similar).
`team`	Team Members: listing members, inviting (link generation), changing another user’s role, removing someone from the Organisation.

If a user lacks Read on a collection, related pages and actions typically disappear or return access errors.

Create limits and read scope

For projects, applications, and servers only, roles can include:

Create limit: when set to a positive number, caps how many of that resource type the user may create in the Organisation. 0 means no numeric cap (unlimited creates, subject to Create being allowed).
Read limit: all versus created by user (restricts which existing records they can see for that collection).

Other collections use plain CRUD flags without these extra fields.

How team permissions map to tasks

Task	Typical permission need
Open Team Members and see the list	team.read
Generate or copy an invite link, change a member’s role	team.update
Remove a member from the Organisation	team.delete

Invites may also be blocked by plan limits on dFlow Cloud (team seat count), independent of RBAC.

Mixed legacy Projects and Applications

During migration from legacy Projects to Applications, both projects and applications rows can matter. Prefer applications / environments / services for new work; see Legacy Projects vs Applications under Core Concepts in the sidebar.