Roles and permissions
The five built-in workspace roles plus custom ones.
Dalea has two scopes of permission: organisation roles (control billing, member directory, workspace creation) and workspace roles (control day-to-day work inside a workspace).
A user has exactly one role per organisation. Org Owners and Admins inherit every workspace permission in every workspace of that organisation: they need no workspace role, and an assigned one neither adds nor removes anything. Plain org Members get exactly one workspace role in each workspace they are added to, and no access at all to the workspaces they are not.
Organisation roles
- Owner
- Everything: invite/remove members, change tier, manage billing, create or delete workspaces, transfer ownership, delete the org. Typically one person.
- Admin
- Like Owner minus billing and org deletion. Day-to-day org administration.
- Member
- Read-only at the org level: see members, see workspaces. Doing work happens at the workspace level via workspace roles.
Workspace roles
Five built-in roles cover most labs. You can also define custom roles with arbitrary combinations of permissions.
- Owner
- Full control. Settings, members, OAuth clients, custom roles, deletion.
- Data Engineer
- Edit documents, comments, inventory and data — including schema changes (with audit reasons). Cannot delete the workspace or manage OAuth.
- Editor
- Edit documents, comments, projects and data records, plus workspace settings, member invitations and calendar assignments. Cannot change the schema or inventory structure, permanently delete data, manage OAuth clients or audit reviews, or delete the workspace.
- Commenter
- Read-only on data and documents. Can post comments.
- Viewer
- Read-only. No comments.
The AI assistant is not role-gated. Any member can open chat; the gate is the
organisation's ai feature, not a workspace permission. Every tool call the assistant
makes still runs under the caller's own permissions, so a Viewer can have it read but
never write.
How permissions actually work
Internally, every action a user can take has a permission name (e.g.
MANAGE_INVENTORY_STRUCTURE, EDIT_DOCUMENTS). Roles are bags of permissions, and
the role hierarchy expands so granting a stronger permission implicitly grants its
weaker neighbours: MANAGE_INVENTORY_STRUCTURE → EDIT_INVENTORY → VIEW_INVENTORY.
This means custom roles can never accidentally elevate above what they grant: you can't grant "edit inventory" without also granting "view inventory".
Inventory tables need both
Item types are data tables now, so designing one sits in both worlds and requires
MANAGE_INVENTORY_STRUCTURE in addition to the usual right to change schema.
Holding one without the other is not enough.
That is deliberate. Someone trusted to add a column to an assay table is not automatically trusted to redefine what a vial of compound is, or to change the unit its stock is counted in.
OAuth client roles
When you create an OAuth client (e.g. for Claude Desktop) you assign it a workspace role. The actual effective permissions when the app makes a call are the intersection of the user's permissions and the app's role: if you are a workspace Owner but you connected Claude with the Viewer role, Claude can only read.
What about platform admins?
Platform-level administration (cross-org visibility, audit health monitoring) is handled exclusively by Dalea's own operations team. Customers — including enterprise tenants — never see or manage other organisations.