Understanding Roles, Permissions and Record Visibility in CrmLeaf
All editions. Core behaviour - no add-on required.
Availability: All editions. Core behaviour - no add-on required.
Overview
CrmLeaf controls access in a way that surprises people coming from simpler systems. Permission is not only "can this person open this screen". For most record types, permission is a scope that decides which records the person sees on that screen. Two users can open the same list and correctly see different numbers of rows, and different totals in reports.
This is the single most common source of support questions, so it is worth understanding before you configure anything or investigate a complaint.
How It Works
Two layers work together.
Role assigned → Module enabled for that role → Permission scope per record type → Records filtered for that user
Layer one: the role
Every new company is created with three roles:
| Role | Intended for | Broad access |
|---|---|---|
admin | Account owners and system administrators | Full access, including settings and configuration |
employee | Staff doing day-to-day work | The work assigned to them, within the modules they are permitted |
client | External customers | Their own tasks and projects, and their own financial documents through the client portal |
Layer two: the permission scope
For each record type, a role's permission is set to one of these scopes:
| Scope | What the user sees | Typical use |
|---|---|---|
none | Nothing. The feature is effectively unavailable. | Modules irrelevant to the role |
owned | Only records they own or are assigned to. | A sales representative seeing only their own leads |
added | Only records they created. | A coordinator who enters records for others to work |
both | Records they own and records they created. | A working team lead |
all | Every record of that type in the account. | A manager, or a reporting role |
A worked example
Example: two people, one Leads screen. An account has 400 leads. Priya is a sales representative whose role has owned on leads, and 32 leads are assigned to her. Arjun is the sales manager, whose role has all.
Priya opens Leads and sees 32 records. Arjun opens the same screen and sees 400. Neither is a fault. If Priya reports that "leads are missing", the answer is her permission scope, not lost data. If she should see more, an Administrator changes the scope on her role, or the records are reassigned to her.
Workspace filtering as well
Where an account uses more than one Organization - a branch, brand or business unit inside the same company - records belonging to other workspaces are also filtered out, independently of the permission scope. So a user can be missing records for two separate reasons at once. See Understanding Companies, Organizations and Workspaces.
Who Can Use This Feature?
Administrator
- Assign roles to users.
- Set the permission scope for each record type on each role.
- Enable modules for roles, within what the account's package includes.
- Investigate "I cannot see my records" reports by checking scope, assignment and workspace.
User
- Work within the records their scope allows.
- Ask an Administrator when a record or screen they need is not visible.
Configuring roles and permission scopes is available only to Administrators.
Important Notes
- A menu layout can hide a feature but can never grant access to it. Access is always decided by the role, the permission scope and whether the module is included and enabled.
- When a paid module is activated, its permissions are added to the roles. Review them afterwards rather than assuming a safe default.
- Reports obey the same scopes. If two people quote different pipeline totals, compare their scopes before assuming a reporting error.
- Clients are real user accounts with the
clientrole. Check what the client portal exposes before inviting a customer. - Role changes take effect for the user on their next sign-in.
Troubleshooting
| Issue | Possible cause | Resolution |
|---|---|---|
| A user cannot see records that exist | Their permission scope is owned or added, and the records are neither owned nor created by them | Change the scope on their role, or assign the records to them |
| A user cannot see a whole module | The scope is none, or the module is not enabled or not included in the package | Enable the module for the role, or confirm plan inclusion. See How to Enable and Manage Add-On Modules |
| Two users report different report totals | Different permission scopes, or different Organization selected | Compare scopes and the selected workspace |
| A newly granted permission has no effect | The change applies at next sign-in | Ask the user to sign out and sign in again |
| Records vanished after switching workspace | Workspace filtering, not permissions | Switch back to the correct Organization |
Frequently Asked Questions
What is the difference between owned and added?
owned refers to records assigned to the user, and added refers to records the user created. They are different sets, which is why both exists. Confirm the exact ownership field for each record type with your Administrator, as it varies by module.
Can I give one person wider access without changing everyone in their role?
Permission scopes are set on roles. Where one individual needs different access, the usual approach is a separate role for that person. Whether an individual override is possible is listed as an open question in Consolidated Information Gaps.
Does an Administrator always see everything?
The admin role is created with full access, but do not assume any specific screen is visible without checking, because module availability still depends on the account's package.
Related Articles
Our support team answers on business days. Reference FM-04 so we can jump straight in.