Security & sharing

Who can open which part of CRM, and what they may do once they are there, is decided by roles and a per-resource permission matrix. Administrators set this up under Admin → Roles; everyone else feels it as the shape of their menu and the occasional refusal. This page is the working detail behind the summary in Customization.

Access is checked on the API, on every request. The web and mobile apps also adjust what they show, but that is presentation — the server is what says no.

Roles

A role is a name plus a matrix. There are no permission sets or profiles: a user’s access is simply the union of every role they hold, so two roles that each allow a little add up rather than cancel out.

The Roles screen lists every role with its code, description, how many users hold it, and whether it is active. Search by name, code or description, and filter by status (active / inactive) or type (system / custom).

Action	Where
Create a role	+ Create Role — a code starting with an uppercase letter, then uppercase letters, digits and underscores (e.g. SALES_REP), a name and an optional description. The code is fixed once created.
Edit name or description	Row action Edit role, or Edit Role & Permissions on the role page
Edit the rights	Row action Manage permissions — see below
Activate / deactivate	Buttons on the role page
Delete	Row action, or the role page. Blocked while any user still holds the role, and hidden on the Admin role.
Add or remove users	Users with this role on the role page — search the active users and tick the ones to add

You can also assign roles from the other end: a user’s edit form carries a Roles multi-select, so onboarding someone and giving them their access is one form.

The Permissions column counts the menu entries a role has a saved row for, not the number of rights ticked — treat it as “has this role been configured yet”, not as a measure of how much it can do.

Admin is the only built-in system role. It is a bootstrap superuser: it bypasses the matrix entirely, its matrix is shown read-only, and it cannot be deleted — so a tenant can never lock itself out of its own administration. Grant it sparingly.

Note

The Assigned Permissions panel on the role page is a leftover from an earlier permission model and stays empty for every role. Rights live in the matrix, which you reach from the Roles list.

The permission matrix

Manage permissions on a role opens a rights grid. Rows are the app’s menu entries, grouped under their menu section — Sales, Service, Marketing, CPQ, Inventory, Admin and Analytics. Groups collapse, so you can work one area at a time.

Eleven action columns are offered. Five of them drive enforcement, and those are the ones to design around:

Column	What it governs
View	Reading the resource — and whether its menu entry appears at all
Create	Creating a new record
Update	Editing a record, and the actions that change one
Delete	Deleting a record
Approve	The approve / reject step on a record — in practice, quote approval

The grid offers six more — Export, Import, Print, Bulk, Share and Clone. They are recorded on the role and survive a save and reload, but they are held for future use rather than checked, so build your access design out of the five above.

Working in the grid:

• Ticking any action auto-ticks View on that row, and unticking View clears the whole row — the combinations that would be meaningless are not reachable.
• Each column header has a select-all that applies to every row in the grid, and each group header has one scoped to that group. Both show an indeterminate state when only some of the rows they cover are granted.
• Save Permissions stays disabled until you change something, then writes the whole matrix in one go. On the Admin role the grid is read-only and there is no save button.

Not every row backs a guarded resource. Some rows only decide whether their menu entry appears; ticking Create on one of those grants nothing extra on the API. The rows that matter for data access are the record areas — around two dozen of them, listed in full under How the API enforces it.

One right sits outside the grid

Authoring customization — custom fields and objects, page layouts, list views, forms, auto-numbering and the automation rules — is gated on a customization right that has no row here, so it cannot be granted from this screen. Today that work belongs to Admin, which bypasses the matrix anyway. Plan for your customization owner to hold Admin, and keep that group small.

How a request becomes an action

The gate is mounted in front of a whole area rather than endpoint by endpoint, so anything added to that area later is covered by default. It works out which action to check from the HTTP method and the shape of the path:

Request	Action checked
GET / HEAD	View
POST to the collection itself	Create
POST beneath a record — a restore, a convert, an ownership transfer	Update
POST to an approve or reject step	Approve
PUT / PATCH	Update
DELETE	Delete

Because the gate belongs to the area and not the endpoint, a record’s sub-resources inherit the parent record’s rights. Adding someone to an account team is a write beneath an account, so it needs Update on accounts; removing them is a delete beneath an account, so it needs Delete on accounts. The same holds for deal products, contact roles, line items and the rest.

The mobile API is gated by the same matrix — it resolves each request to the same resource names and reuses the same method-to-action rules, so a role that can only view deals in the browser can only view deals on the phone. The app is not a way around your access design. Coverage across the two surfaces is close but not identical, so it is worth trying a new role on both before you roll it out. See Permissions on mobile.

Navigation

The sidebar is built from the same matrix. A menu entry appears when the user has View on it through one of their roles, and a menu heading appears automatically when anything under it is visible — you never have to grant the heading separately. The Admin role sees the whole menu.

Your own profile is always reachable from the avatar in the app header, regardless of the matrix.

The Android app’s drawer is not filtered this way; it shows every section to everyone and reports a load failure if the role cannot view one. The permission still holds — it is enforced on the API — but the menu is not a guide to it.

In the web app

When you sign in, the app fetches your effective permissions — the union across your roles — in one call, and uses them for two things:

• Opening an area you cannot view renders a clean “You don’t have permission to view this.” page instead of a broken screen.
• When the server refuses an action, the reason is surfaced as a message rather than a silent failure.

This guard deliberately fails open. If the permissions call has not finished, or fails, or the route is not one it recognises, the page renders anyway — the underlying data calls are refused by the API regardless, so failing open costs nothing and never wrongly locks out a legitimate user. Do not read a visible page as evidence of a granted right.

Integrations can read the same effective matrix for the signed-in user from the API, which is how an embedding app can gate its own controls consistently.

When a change takes effect

Change	Takes effect
Editing a role’s matrix	On the next request. Every cached answer for the tenant is dropped when you save, with a five-minute expiry as a backstop.
Adding or removing a user’s role	On the next request, for that user.
Granting or removing Admin	Admin membership travels in the sign-in token, so it lags until the session’s token is refreshed — within about an hour, or immediately if the user signs out and back in.
What the browser shows	The effective-permission list is fetched once per session. An open tab keeps showing the old menu and guard until the page is reloaded or the user signs in again.

Record ownership and teams

Every lead, account, contact, deal and case has an owner, and quotes, orders and the rest carry the same idea. Ownership drives assignment rules, forecasting roll-ups and the reports that break results down by rep, and it can be handed over with transfer ownership on the record. On the list pages, Owner is one of the filters, and you can save the filtered list as a personal view — the practical way to give someone a “my accounts” screen.

Two named teams sit alongside ownership:

• Account team — on the account record. Add a user with a team role (Account Owner, Account Manager, Sales Rep, Account Executive, Customer Success, Solution Engineer, Support, Other) and four access settings: Account (Read / Edit) plus Opportunity, Case and Contact (None / Read / Edit) for the records that hang off the account. Members are listed with their role and account access, and can be removed.
• Deal team — on the deal record. Add a user with a team role (Sales Rep, Sales Manager, Account Executive, Solution Engineer, Partner, Other), an access setting (Read / Edit) and an optional revenue split percentage. The panel totals the splits and flags the total when it is not 100%.

Both panels record every add and remove in the record’s audit trail. Neither has an inline edit control: to change someone’s team role or access, remove them and add them back.

Team access levels are recorded, not enforced

The access levels you choose on a team member are stored, shown and audited — but nothing restricts visibility by them. CRM has no record-level sharing today: a role with View on accounts can see every account in the tenant, whether or not the user owns it or sits on its team, and the same is true of leads, contacts, deals and cases.

Use owners and teams for assignment, reporting, revenue split and knowing who to ask — not as a confidentiality boundary. If some records must not be seen by part of your team, CRM cannot enforce that for you.

What the matrix does not cover

Caution

A few areas of the app are still gated on sign-in alone rather than on the matrix, so any signed-in user in the tenant can reach them whatever their role says. Do not treat unticking a right as a guarantee that covers the whole product: for now, tenant sign-in is the real boundary, and an account should only go to someone you would trust with those areas.

The six extra columns in the grid above are the same story — recorded on the role, not checked.

Good practice

• Give each role the least it needs, and build up. Because roles union together, it is easier to add a second narrow role than to unpick a broad one.
• Keep Admin to the smallest possible group; it bypasses everything.
• Review assignments when people change teams — a role assignment stays until someone removes it, and the Users column on the Roles list makes strays easy to spot.
• Design around the five enforced actions only, and remember that record visibility is tenant-wide: a plan that depends on hiding records from part of your team will not hold.
• Treat tenant sign-in as the outer boundary. Some capabilities sit outside the matrix, so give an account only to someone you would trust with the tenant.

Connects to

• Customization — the metadata this matrix gates, the full list of guarded resources, and the customization right that governs authoring it.
• Automation — approvals, and how the named approver on a step, rather than the matrix, decides who signs off.
• Mobile app — the same matrix on the phone.
• Roles & permissions — how the suite’s other products express access control.