Skip to main content
For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt. This page is also available in markdown by appending .md to the URL.
This guide is part of the User Guides collection. It is for admins who decide who can see and change what. If you are setting up a new environment, do this after Admin and setup step 1, once your team is invited.
A role answers two questions for every person in your organization: what they can see, and what they can change. Coverbase ships six roles that cover most teams. When none of them fits, you build a custom role by turning individual permissions on and off.
Custom roles are a gated feature. If you do not see Roles under Settings, it has not been switched on for your organization yet. Ask your Coverbase contact. The six default roles work either way.

​
The six default roles

Every member holds exactly one role. These six ship with the product and cannot be edited, but you can clone any of them as a starting point. Start with Member for anyone on the risk team and Admin for the one or two people who own the program. Reach for a custom role only when a real job does not fit.
Service Account is the role your API keys use. Every key your organization issues authenticates as it, so editing that role changes what your integrations can do. One rule to know: a service account can request a change to supplier bank details but cannot approve one. Approving stays with a person.
Understand Siloed Member before you assign it. It does not hide a smaller list of features. It shows the same features against a smaller set of records: the vendors and assessments that person owns, watches, or analyzes. If someone says a vendor “disappeared”, check whether they are a Siloed Member who was removed as an owner.

​
How a permission is built

Every permission in Coverbase is three things joined together.

Resource

The thing being acted on. Vendors, assessments, findings, contracts, controls, API keys, and 27 others.

Action

What you are doing to it: read, create, update, export, assign, approve, comment, archive, or run.

Scope

How much it covers: every record in the organization, or only the records that person is assigned to.
“A Member can update any vendor in the organization” is the resource vendor, the action update, and the scope all records. “A Siloed Member can update the vendors they own” is the same resource and action at a narrower scope. Not every combination exists. Some resources have no per-record assignment, so scope does not apply to them: there is no such thing as being assigned to an API key or to organization settings. Those are always organization-wide, and the editor shows them that way.

​
Finding the role editor

Go to Settings, then Roles. The left side lists every role in your organization, with a Default role badge on the six that ship with the product. Selecting one opens its permission matrix. Default roles are read-only. To base a new role on one, open it and choose Clone.

​
Reading the permission matrix

The matrix has one row per resource and one column per action. Each cell holds one of four values. Click a cell to cycle it through no access, assigned only, and all records. Right-click to pick a value directly. Use Filter by resource or action to narrow a large matrix while you work. Assigned scope is not available everywhere. A resource with no assignment model only offers all records or no access, and the cell says so when you hover it.

​
The rules the editor enforces

Some combinations describe a role the product cannot deliver. The editor catches those before you save, shows them in a banner at the top, and offers Fix all.
You cannot give someone update, approve, assign, archive, export, comment or run on a resource without also giving them read at the same scope. Editing a record you cannot open is not a narrower permission, it is a broken screen.The fix is to raise read to the scope the other action needs.
Assessments, findings, commitments, services and Radar alerts are all reached through a vendor. Granting one of them without vendor read produces a page the person cannot open. The editor requires vendor read alongside any of these.
A role that can create records but not read them is unusual, and the banner says so, but it saves. It is a real pattern for an intake submitter or a write-only integration that files records it never lists.
If your own role does not include a permission, you cannot give it to another role. Admins hold everything, so this never limits them. It matters when you delegate role management to someone who is not an Admin: they can build roles up to their own level of access, and no further.To create a role broader than your own, ask an Admin to do it.
Editing the role you yourself hold, you cannot remove its ability to read and manage roles. Doing so would leave you unable to reopen the editor and undo it. Another Admin can still change your role for you.

​
Building a custom role

1

Start from the closest default

Open the default role nearest to what you want and choose Clone, or choose New role to start from nothing. Cloning is usually faster, and it starts you from a set that already passes the rules above.
2

Name it for the job, not the person

“Contract reviewer” outlasts “Priya’s role”. Names show up in the member list and in the audit trail.
3

Set the matrix

Work resource by resource. For each one, decide read scope first, then the actions on top of it. Filtering by resource keeps you out of the rest of the matrix while you do it.
4

Clear the banner

Fix anything the validation banner reports. Fix all applies the minimum change that resolves each issue, which is usually adding the read the other permission depends on.
5

Save, then add members

Members can only be added to a saved role. Save first, then use the members panel.

​
Assigning people to a role

The members panel on a role shows everyone who holds it. Add someone with Add to role, and remove them with Remove from role. Two things are blocked:
  • The last Admin cannot be demoted or removed. Make someone else an Admin first. This applies whether you are removing them from the Admin role or assigning them a different one.
  • Changing your own role asks for confirmation. If the change removes your own administrative access, you lose it immediately, and only another Admin can give it back.
Members always hold a role. To move someone out of a role, add them to a different one rather than removing them from their current one.

​
What custom roles do not restrict

A few areas are visible and actionable for every member regardless of role. They are listed in the editor under Not restricted by custom roles so you are not left looking for a toggle that does not exist. Some surfaces have no toggles of their own because they follow the records they act on. Email, engagements, Coverbase AI and Radar signals inherit the permissions of whatever they are acting on. Configuration pages follow the permission for the thing they configure. Clause sets follow contract permissions. The risk scale and Document Insights settings follow organization settings.

​
Seeing what changed

Every role carries its own activity log, on the role itself. It records who changed the role and what they changed, so a permission that appeared or disappeared can be traced to a person and a time. A newly created role has no activity until it is saved. Role changes also appear in the organization-wide audit trail alongside everything else. See Audit trails.

​
Troubleshooting

Admin and setup

The full setup sequence. Roles come after inviting your team.

Audit trails

Every recorded event, including role and membership changes.

API keys

Service accounts and scoped keys for integrations.

MCP permissions

How the same permissions apply when an AI assistant acts on your data.