Workspace settings
Roles, user types, permissions and visibility groups
In Dalil, access management is built from three connected concepts: user types, permissions, and visibility groups.
Think of it this way: the user type defines the general power a person has, permissions define the actions they can perform, and visibility groups define which records they can actually see.
Let’s go step by step.
User types
Every person you invite to Dalil must be assigned a user type. This is the broadest level of control:
Super Admin has complete control. They can view and edit all records, change settings, manage billing, and configure integrations.
Admin has access to most data and features, but usually cannot delete workspaces or override billing and domain settings.
Member has limited access and mainly works with their own records or the records visible to their group.
Guest is an external collaborator with minimal access, usually invited only to see or comment on specific items.
For example, if you add an external consultant who only needs to see notes related to a project, you make them a Guest. If you are the founder of the company, you will remain a Super Admin because you need access to everything.
Permissions
Inside each user type, you can fine-tune what people can do with entities like People, Companies, Opportunities, Tasks, or Notes.
For each entity, you can allow or deny five basic actions: Create, Read, Edit, Delete, Assign.
Each action can be set to one of three levels:
Full access means the user can perform that action everywhere in the workspace.
Restricted means the user can only perform that action where their visibility group allows it.
Not allowed blocks the action completely.
For example, let’s take an Admin role. If you set “Read” on Companies to Restricted, then the Admin will only see companies inside their visibility group. But if you set “Read” to Full access, they will see companies across all groups, even if visibility would normally block it.
⚠️ This is important: permissions can override visibility. If you grant an Admin “Read: Full access,” then even if their group is limited, they will still see all records.
Visibility groups
Permissions decide what a user can do.
Visibility groups decide which records they can see or edit.
You create groups that usually reflect how your company works: for example, UAE Sales, KSA Sales, or Customer Success. A user is then assigned to one or more of these groups.
When editing a visibility group in Dalil, you can choose from four levels of visibility for each entity (People, Companies, Opportunities, etc.):
Owner only: only the record’s owner, Admins, and parent group users can see it.
Owner’s visibility group: all users in the same group, plus Admins and parent group, can see it.
Owner’s group and sub-groups: the group, its sub-groups, the parent group, and Admins all share access.
Entire company: all workspace users can see it.
Let’s go back to the UAE Sales vs. KSA Sales example. If the UAE Sales group is set to Owner’s visibility group, then only people in UAE Sales, plus Admins and parent groups, will see those opportunities. Someone in KSA Sales won’t see them unless they are explicitly added or their role gives them Full access rights.
If instead you configure UAE Sales to Owner’s group and sub-groups, then not only UAE Sales but also its parent group (e.g., “Middle East Sales”) and any sub-groups will be able to view and edit those records.
This is why visibility groups are powerful: they let you replicate your company hierarchy directly in Dalil.
Putting it together
The three layers always work together:
User type sets the baseline (Super Admin, Admin, Member, Guest).
Permissions decide the specific actions a user can take (create, read, edit, delete, assign).
Visibility groups decide which records the user can access (Owner only, Owner’s group, etc.).
Here is a concrete scenario:
A salesperson is a Member in the UAE Sales group.
Their permissions are “Read: Restricted” on Opportunities.
Their group visibility is set to Owner’s visibility group.
Result: they can only see opportunities owned by people in UAE Sales.
Now compare with their manager:
The manager is an Admin in the same group.
Their permissions are “Read: Full access” on Opportunities.
Result: they can see all opportunities across the workspace, even those from KSA Sales, because Full access overrides visibility.
Tips for managing access
Start simple. Begin with one visibility group (e.g., “Default Company”) and expand into sub-groups later as your org grows.
Test with a dummy account before assigning roles to your team, so you see exactly what the user will see.
Use “Restricted” permissions whenever you want groups to work independently, and only upgrade to “Full access” when someone truly needs visibility across groups.
Remember: “Restricted” means visibility group rules apply, but Admin roles can override that if you give them full rights.