Roles, Teams & Permissions

The two halves of access

EspoCRM controls access with Roles and Teams, working together:

• Roles decide what a user can do — which record types they can see, create, edit, or delete, plus any administrative abilities.
• Teams decide whose records a user can see — records are shared with teams, and members of a team can see them.

A user can hold several roles and belong to several teams; their effective access is the combination.

Roles

• Administration → Roles.
• A role grants permissions per record type (Contacts, Engagements, Sessions, …) — typically None / View / Edit / Create / Delete — and a scope (all records, just their team's, or just their own).
• CBM's roles are already set up to match job functions. Prefer assigning an existing role over inventing new ones.

Least privilege: give people the access their job needs and no more. Widening access later is easy; clawing it back after data has been over-exposed is not.

Teams

• Administration → Teams.
• Teams group users and act as the unit of record sharing.
• Add someone to a team from either the user record or the team record.

How they combine — an example

A mentor holds the Mentor role (view/edit engagements for their team, no delete) and belongs to the team that owns their engagements → they see and update their engagements and session notes, and nothing else.

Changing roles or teams safely

• A role or permission change affects everyone with that role at once.
• Test in the Sandbox first (the golden rule from Signing In & the Administration Panel): confirm a typical user sees exactly what you intend, then apply in Production.
• After the change, spot-check with a real user in that role.

Permission changes that broaden access can expose data unintentionally. Treat them like configuration changes (Chapter 3), not casual edits.