Users, Roles & Access
Managing who can sign in and what they can see and do.

Managing Users
What a user is
Anyone who signs into the CRM has a user record. Each person should have their own account — never a shared login. Individual accounts keep the activity history accurate (who logged which session, who changed what) and let you remove someone's access cleanly when they leave.
Types of user
Type
Who it's for
Regular user
Staff and mentors who sign in and do everyday work.
Administrator
Can reach the Administration panel and change system settings. Grant this to as few people as possible.
API user
Non-human accounts used by integrations (e.g. the website or documentation tooling). You'll rarely create these.
Portal user
External people using a limited portal, if CBM uses one.
Adding a user
Administration → Users → Create User.
Enter their name, User Name, and Email Address.
Set the Teams and Roles that match their job — this is what controls what they can see and do (see Roles, Teams & Permissions).
Decide whether they're an administrator (usually no).
Save — then either set a password or have the CRM email them a setup link (recommended if email is configured).
Get teams and roles right at creation time. They govern the user's access; skip them and the person may see far too much or too little.
Resetting a password
Open the user → Actions / ⋮ menu → Change Password, or
Have the person use "Forgot password?" on the login screen (requires outbound email — see Chapter 5 — Integrations).
When someone leaves: deactivate, don't delete
Open the user and turn Is Active off. This blocks sign-in but keeps all their history intact and correctly attributed.
Avoid deleting users — deletion can orphan or reassign the records they created. Deactivating is almost always the right move.
Deactivate first. You can always reactivate; undoing a delete is far harder.

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.