Roles and permissions matrix
Choose the smallest workspace role that supports each customer job.
- For
- Company admins and security reviewers
- Owner
- Identity and access
- Outcome
- Assign a role and prove both an allowed and a denied action before launch.
- Last verified
- 2026-08-30
- Next review
- 2026-11-28
- Status
- supported
Customer journey
Configure roles and access
- Estimated time
- 15 min
- Permissions and roles
- Company admin · Security reviewer
Open the completion checklistSteps, proof, and recoveryClose checklist
Prerequisites
- A confirmed team structure
- The customer ownership and approval model
- A representative account for each role
Permissions in practice
- Company admin: assign roles, teams, ownership, and provider access.
- Security reviewer: approve one allowed and one denied action for each role.
Steps
- List the exact customer jobs and data scope for every user group.
- Assign the smallest role that can complete those jobs.
- Test one permitted action and one restricted action with representative accounts.
- Confirm team scope, record ownership, export, integration, and deletion boundaries.
- Record the approver, review date, and process for removing temporary access.
Success proof
- Each role completes its approved job without borrowing another account.
- Each restricted action fails clearly and does not require a broader role as a workaround.
Common failures
- A user is in the wrong workspace, team, or ownership scope.
- Access is increased to bypass an unclear route or error.
Recovery
- Check the user, workspace, role, team, record owner, and exact route in that order.
- Use permission and audit evidence to correct the smallest missing boundary.
Rollback
- Remove temporary access after the approved work is complete.
- Restore the last approved role assignment and record the change owner.
Next task
Run the first lead-to-deal acceptance path.
This matrix describes the normal public workspace boundary. Exact object access can also depend on ownership, team scope, and configured policies. Test every customer role in its own workspace.
Core workspace permissions
Use this table as the starting point. A company admin can create narrower custom roles and policies where the product supports them.
| Customer job | Frontline user | Manager | Company admin |
|---|---|---|---|
| Work assigned customer records, deals, tasks, and approved communication | Yes | Yes | Yes |
| Review team work, reports, assignments, and operational queues | Limited | Yes | Yes |
| Invite users and manage teams, roles, and permissions | No | Limited by policy | Yes |
| Configure company fields, sources, pipelines, and operating rules | No | Limited by route | Yes |
| Configure provider connections, API clients, and company credentials | No | No | Yes |
| Manage privacy, compliance, exports, and offboarding controls | No | No | Yes |
Super administrator access is an internal platform role. It is not a customer workspace role and is not part of this public matrix.
Verify each role
- List the exact customer jobs for the role.
- Assign the smallest role that can complete those jobs.
- Test one permitted action and one restricted action with a representative account.
- Confirm team scope, ownership, export, integration, and deletion boundaries.
- Record the approver and review date.
Resolve access problems
- Confirm the user, workspace, role, team, record owner, and exact route.
- Do not increase access only to bypass an unclear error.
- Use the permission and audit views to explain the decision.
- Remove temporary access after the approved work is complete.