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.