Roles & permissions

Every product in the suite asks the same question of a request: may this user do this to this? How widely it asks differs by product — that is the substance of this page — but the vocabulary is shared. People are users, users hold roles, and a role carries a matrix — a grid of resources against the actions that may be performed on them. The screen you edit that grid on is literally the same component in all three products, which is why the CRM, CPQ and Accounts role editors look and behave alike: it comes from the suite’s shared component library rather than being rebuilt three times.

What is not shared is the engine behind the grid. CRM, CPQ and Accounts each grew their own enforcement, at different times and to different depths, and they have not been merged. This page is the model to understand before you configure roles anywhere in the suite, plus a plain account of where the three diverge — because the differences change how you should design roles in each.

There is no suite-wide role

Each product keeps its own users and its own roles. Somebody who works in both CRM and Accounts holds a role in each, granted separately, and editing one has no effect on the other. There is no role that grants access everywhere at once, and no single screen that shows a person’s access across the suite. Plan access product by product — see Add your team for how users get into each one.

The shared model

Users. The people in a product’s workspace. CRM and CPQ create their own users, and an administrator chooses their access on the same form that creates the account. Accounts does not create users at all: its user list is a read-only directory provisioned with the workspace, and the only thing you do there is decide which roles those people hold.

Roles. A role is a name plus a matrix. There are no permission sets, profiles or role hierarchies in any of the three — a role is the whole unit of access, and in CRM and Accounts a user’s access is the union of every role they hold. The practical consequence is that roles only ever grant: two roles that each allow a little add up, and there is no way to author a role that takes something away. Build access up from narrow roles rather than trying to carve exceptions out of a broad one.

Resources and actions. The matrix rows are the things you can act on, and the columns are the actions. What counts as a row differs by product (see the table below), but the idea is constant: a role either may view a resource or it may not, and separately may create, change or delete within it.

A superuser exists in all three, so a workspace can never lock itself out of its own administration. It bypasses the matrix entirely rather than being a role with every box ticked, and it should go to the smallest possible group.

The server is the boundary; the menu is manners. All three web apps fetch the signed-in user’s effective rights and use them to shape the navigation. CRM and Accounts go further and guard a whole screen, showing a clean refusal instead of a broken one; CPQ filters its menu only. None of them treats any of that as the control, and the two apps that do guard a screen — deliberately fail open: while the rights answer is in flight, or if the request for it failed, the screen renders rather than refusing. CPQ filters its menu from the same rights but has no separate screen guard to fail either way. A visible menu entry is therefore never proof of a granted right, and a hidden one is never proof of a withheld one.

The server does its own check rather than trusting what the browser was shown — but how completely it does so differs by product, and none of the three checks literally every request. Accounts stands its check once, in front of the data routes as a whole, which is the strongest of the three: a route added tomorrow is gated the day it exists. CRM mounts its check in front of each guarded area, so those areas are covered end to end, including anything added to them later, while the rest of the product is reached by any signed-in user. CPQ declares the check endpoint by endpoint, so coverage is per operation rather than per area. The row Where the check is mounted in the table below is the same fact at a glance.

An administrator should take one thing from that: a role shapes more of Accounts than it shapes of CRM or CPQ, and in none of them is it a containment boundary. Read What the matrix does not cover before you rely on one.

How a request becomes a decision

Two of the three products work out the required action from the request itself rather than from a list somebody maintains by hand: reads need view (or read), writes need create, update, delete or write according to the method and the shape of the path. That matters more than it sounds: a sub-resource inherits the rights of the record it hangs off, so adding somebody to an account team in CRM is a change to the account and needs Update on accounts — nobody had to think of that case and write it down.

The mapping is documented per product, with the exact method-to-action table, on Security & sharing for CRM and Security for Accounts. CPQ takes the other approach: each endpoint declares the permission it needs.

Where the three differ

	CRM	CPQ	Accounts
Where roles are edited	Admin → Roles	Settings → Roles	Settings → Roles & permissions
Users created in the product	Yes	Yes	No — read-only directory
Roles per user	Any number; access is the union	One	Any number; access is the union
What a matrix row is	A menu entry	A menu entry	A route group, derived from what the server actually serves
Actions on the grid	Eleven offered, five checked	Four	Read and Write per group
Where the check is mounted	In front of each guarded area	Declared endpoint by endpoint	Once, in front of the data routes as a whole
Superuser	The built-in Admin role	A role named admin or superadmin	An all permission, grantable to any role
Enforcement can be switched off	No	No	Yes — a deployment setting, enforcing by default in production
Grants can be time-limited	No	No	Yes — an expiry date per assignment
Record-level visibility rules	No	No	No

A few of those rows deserve a sentence each.

CRM — the widest grid, only part of it checked

CRM’s grid offers eleven action columns. Design your access out of the five that are enforced — view, create, update, delete and approve. Those are the ones the server consults, and they are enough to express most of what a role needs to be.

The remaining six columns — export, import, print, bulk update, share and clone — are held for future use. They save on the role and survive a reload, but nothing checks them, so an unticked box in one of those columns is a note of intent rather than a control. It is worth knowing which six they are precisely so that you do not build a role around one and believe it is holding. Where one of those capabilities genuinely has to be withheld, the control that exists is View on the underlying record area: someone who cannot read a resource has nothing to export, print or share from it. The full grid, its select-all behaviour and the list of resources it actually governs are on Security & sharing.

One right sits outside the grid altogether. Authoring customization — custom fields and objects, layouts, list views, forms, numbering and the automation rules — is gated on a right that has no row to tick, so that work belongs to Admin today. Plan for your customization owner to hold Admin and keep that group small; see Customization and Customizing the suite.

CRM’s mobile API resolves a request to the same resource names and the same actions as the web routers, so a role behaves on the phone the way it behaves in the browser and the phone is not a separate, laxer access design. It is not a stricter one either: where an area of CRM is governed by signing in rather than by the matrix, the same is true of it on mobile. Try a new role on both surfaces — see Mobile app.

CPQ — one role per user, four actions

CPQ is the one product where a user holds a single role, chosen on the user form, so there is no union to reason about: that role decides both what appears in the menu and what the API allows. Its rights grid offers four actions — view, create, update and delete — grouped by module and menu, and saving writes only the entries you changed.

Two consequences worth planning around. A handful of CPQ operations require approve, export or import rather than the four the grid offers, and since those cannot be ticked on the Roles screen they are effectively reserved for the superuser roles today; approvals in particular are usually better handled through the approval process itself, which names its approver as a specific user or an approver role independently of the matrix — see Quotes & approvals. And because CPQ carries the user’s role in the sign-in token, changing which role somebody holds takes effect when they next sign in, not immediately.

CPQ also has two access models that sit outside the internal role matrix entirely. Portal users — customers, partners and vendors — are a separate identity with their own directory record and their own sign-in; the customer portal user additionally carries a role of its own and a set of per-user switches. Read Portals before you promise a customer portal access, because which portals can actually be signed in to today is narrower than the screens suggest. And in the field service app the server scopes a technician’s requests to their own assignments and refuses the company-wide view to anyone without a manager-like role (Mobile apps).

Accounts — a gate in front of everything, fail-closed in production

Accounts mounts its permission check once, ahead of the data routes as a whole, so a route added tomorrow is gated the moment it exists and the work is to grant access rather than to remember to withhold it. Its vocabulary is a read and a write grant per route group, and the catalogue the role editor offers is generated from the routes the server has actually mounted — so the editor cannot offer you a permission the gate has never heard of. A write grant implies the matching read, and the grid shows that rather than pretending otherwise.

Two things are unique to Accounts. Enforcement is controlled by a deployment setting that defaults to enforcing in production: warn-only has to be chosen deliberately, and when a server is in warn-only mode the Roles screen says so in a banner instead of letting you believe your roles are biting. The app is consistent about it: in warn-only mode the browser gates nothing at all either, on the reasoning that hiding a button the server would honour tells the user something untrue about the system in front of them. And a role grant can carry an expiry date — useful for contractors and leave cover — after which it simply stops counting. Both are described on Security.

The gate is sound; the seeded grants have lagged behind it. The standard Accountant and Tester roles were seeded with the route groups that existed at the time, and several areas that shipped later were never added, which shows up as a refusal or a missing navigation entry on a feature the role legitimately owns. The fix is to open the role and tick the group. Which ones, and why, is on Security and Implementation verdict.

What the matrix does not cover

Sign-in is the real boundary

In each of the three products, some capabilities are governed by signing in rather than by the permission matrix, so any signed-in user in that workspace can reach them whatever their roles say. How much is involved differs by product and is smallest in Accounts, whose gate stands in front of the data routes as a whole — but it is not zero anywhere.

Design access on that basis. Unticking a right narrows what somebody can do; it is not a guarantee that covers a whole product. Treat a role as a way to shape somebody’s working day, not as a containment boundary, and give an account only to someone you would trust with the workspace.

No product restricts visibility by record. Owners, account teams, deal teams and quote teams exist across the suite, and the access levels you set on a team member are stored, shown and audited — but nothing hides a record from someone whose role can view that resource. A role with View on accounts sees every account in the workspace. Use ownership and teams for assignment, reporting, revenue split and knowing who to ask; if some records genuinely must not be seen by part of your team, none of the three products can enforce that for you. Security & sharing covers what ownership and teams do give you.

The exceptions are the surfaces that were built scoped from the start rather than being governed by the matrix at all: CPQ’s field service app, described above, and the customer portals, which authenticate one contact and show only that contact’s account (CPQ, Accounts).

When a change takes effect

Change	CRM	CPQ	Accounts
Editing a role’s rights	Next request	Next request	Next request
Giving or removing a role	Next request	When the user next signs in	Next request
Granting or removing the superuser	When the session’s token refreshes — within about an hour, or immediately on sign-out and back in	When the user next signs in	Next request
What the browser shows	Fetched once per session; an open tab keeps the old menu until it is reloaded	Menu is loaded with the session	Re-checked every few minutes, and immediately in the tab where the role was saved

CRM’s timing, including how its cached answers are dropped when a matrix is saved, is set out on Security & sharing.

Good practice

• Give each role the least it needs, and build up. Where roles union together, a second narrow role is easier to add than a broad one is to unpick.
• Keep the superuser group tiny. In every product it bypasses the matrix outright, and in CRM it is additionally the only way to grant customization authoring.
• Keep finance separate from sales. Accounts is the ledger of record; the people who quote and the people who post to the books should hold different roles, in different products, granted to different lists of names.
• Remove the assignment when you mean to remove access. Taking the role away from the person is the clean, unambiguous change — immediately in CRM and Accounts, at their next sign-in in CPQ. Deactivating a role or clearing boxes in its grid is a blunter instrument that also affects everybody else holding it.
• Review assignments when people change teams. An assignment stays until somebody removes it. In CRM and CPQ the Roles list shows how many people hold each role, which makes strays easy to spot; in Accounts, prefer an expiry date on any grant you already know is temporary.
• Try a new role on one person before you roll it out. Have them walk the work they actually do, on the web and on the phone. Coverage across the two surfaces is close but not identical, and a missing grant shows up as a refusal or a missing menu entry rather than as anything on the Roles screen.
• Turn Accounts’ enforcement on before you load real books, and check the Roles screen is not showing the warn-only banner.

Where the detail lives

• CRM · Security & sharing — the full rights grid, the method-to-action mapping, ownership and teams, and what the matrix does not cover.
• CRM · Customization — the metadata the matrix gates and the customization right that governs authoring it.
• Accounts · Security — the gate, fail-closed enforcement, sign-in protection, sessions and the seeded-grant caveat.
• Accounts · Implementation verdict — an independent point-in-time assessment, including where the grants stand.
• CPQ · Portals — the customer, partner and vendor logins that sit outside the internal role model.
• Customizing the suite — who may author the fields, layouts and rules the matrix gates.
• One source of truth — what the products share, and what each keeps to itself.