Roles and permissions
Define user roles with record-level and settings permissions, set object-level overrides, and control exactly what each team member can see and do.
As a workspace grows beyond a founding team, "everyone can do everything" stops being acceptable: SDRs shouldn't delete companies, contractors shouldn't export your database, and only admins should touch the data model. Roles define what each member can see and do.
Open Settings → Roles to see all roles, create new ones, and assign members. You can also set a default role for the workspace, applied to new members automatically.
What a role defines
A role has a name, an optional description, and two permission layers:
Record permissions
What the role can do with CRM data, workspace-wide:
- See Records on All Objects
- Edit Records on All Objects
- Delete Records on All Objects
- Destroy Records on All Objects (permanent deletion, beyond the recoverable delete)
Settings permissions
What the role can administer. Either grant Settings All Access ("ability to edit all settings"), or pick individual areas:
| Permission | Grants |
|---|---|
| Workspace | Set global workspace preferences |
| Users | Add or remove users |
| Roles | Define user roles and access levels |
| Data Model | Edit CRM data structure and fields |
| API Keys & Webhooks | Manage API keys and webhooks |
| Security | Manage security policies |
| Admin Panel | Admin settings and system tools |
Object-level overrides
Beyond the workspace-wide toggles, a role can carry per-object permissions: the ability to interact with each object individually. Use this for roles like:
- SDR: full access to People and Companies, read-only on Opportunities
- Finance: read access to Opportunities, no access to outreach objects
- External contractor: access only to the one pipeline they work in
Use Toggle all object permissions as a starting point, then adjust the exceptions.
Assigning members
From a role's Assignment tab, search and assign workspace members. Each member's access comes from their assigned role; reassigning takes effect immediately. When you assign someone who already holds another role, Dalil shows exactly which role they'll be unassigned from before you confirm.
Role and permission changes generate notifications (User and Permission Changes), so affected members know their access changed.
AI agents and roles
Roles don't just govern humans: AI agents can also be scoped by role, so an AI CRM agent operates with defined permissions rather than full workspace access: the same least-privilege logic you apply to people.
Recommended setup
- Admin: Settings All Access; keep it to 1–2 people
- Manager: record permissions across objects; settings limited to Users
- Rep: see/edit records, no delete, no settings
- Set Rep as the workspace default role, so new invites start safe and get elevated deliberately
Key outcome
Roles make Dalil safe to scale: every member gets exactly the access their job needs, destructive actions are restricted to people accountable for them, and the data model, security, and API surface stay under admin control.
Was this article helpful?
Your feedback helps us improve our documentation.