Roles and permissions
How access control works — and why data scope is the part that matters most.
Administration → Roles & Permissions.
A role carries two independent things. Getting the second one right matters more than the first.
Permissions — what someone can do
A flat list of exact capabilities: leads.view, leads.write, calls.dial, reports.export, users.manage, and so on.
Permissions are exact match. There are no wildcards. A role holding leads.view does not automatically receive leads.delete when we add it in a future release.
This is deliberate and it differs from most systems. A wildcard permission means every new capability we ship is silently granted to everyone who already had something related — which is how people end up with rights nobody decided to give them.
Data scope — what someone can see
Separately, each role has one data scope:
| Scope | Sees |
|---|---|
| Own | Only records they own |
| Team | Their team's records |
| Location | Their location's records, including sub-locations |
| Org | Everything |
own cannot reach a colleague's lead by editing a URL, because the row is not in the result set at all.This is the difference between hiding something and it being inaccessible, and it is the thing to verify if you are completing a security review.
The default roles
| Role | Permissions | Scope |
|---|---|---|
| Super admin | Everything | Org |
| Manager | Most, minus billing and roles | Team |
| Team lead | Lead and activity management | Team |
| Telecaller | Work their own leads | Own |
| Viewer | Read-only reports | Team |
These cover most organisations. Change them rather than starting from scratch.
Sensitive permissions
Some permissions are marked sensitive and are worth granting narrowly:
reports.export— taking data out of the productcalls.recordings— listening to recorded conversationsusers.impersonate— acting as another memberaudit.view— reading the audit trailsettings.manage— changing workspace configuration
reports.export in particular is separate from reports.view on purpose. Being able to read a report on screen and being able to walk out with the underlying rows are different rights.
API tokens
Settings → API tokens. A token is bound to one membership and can hold a *subset* of that membership's permissions.
A token narrows; it never widens. A token issued by a super admin with only leads.view really can only read leads — the super admin's blanket access does not leak through it.
Auditing access
Every permission change, role change and login is recorded with the actor, their IP and device. Reports → Audit Trail, if you hold audit.view.
The trail includes field-level diffs, so "who changed this lead's owner last Tuesday" has an actual answer.
Something unclear or missing? Tell us and we will fix the page — send us a note.