Roles, Teams & Permissions

The two halves of access

🚧EspoCRM controls access with ThisRoles pageand 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 beingthe written.combination.

Roles

It

willAdministration cover:→ howRoles. 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 teamsno controlmore. whoWidening canaccess 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 doupdate what,their engagements and howsession tonotes, adjustand 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 safely.like configuration changes (Chapter 3), not casual edits.