PLT-06Core CrmLeafAdministrator

How to Configure Ownership-Based Permissions in CrmLeaf

All editions. Core feature - no add-on required. Permissions for add-on modules appear only after the module is enabled for your account.

Part 1 · Platform Setup and Administration9 min readIncludes a Service / PSA lens

Availability: All editions. Core feature - no add-on required. Permissions for add-on modules appear only after the module is enabled for your account.

Overview

CrmLeaf permissions are not simple on or off switches. Each permission carries a scope, and the scope decides which records a user sees inside a module, not only whether the page opens. This is the single most important configuration decision in the platform, and the most common source of support questions such as "why can my colleague see this lead and I cannot?".

This article explains the five scopes, how to choose between them, and how to verify the result.

How It Works

There are two layers. The first is the role - admin, employee or client - which establishes what kind of participant a user is. The second is the fine-grained permission set attached to that role. For each permission, CrmLeaf resolves a scope value rather than a yes or no answer, and the module's record lists are filtered using it.

Role → Permission per module → Scope resolved → Records filtered → Organization filter applied → What the user sees

The five scope values are none, owned, added, both and all.
Filtering happens where the records are fetched, so it applies consistently to lists, boards, dashboards, reports, the mobile app and AI assistant access - not just to the page itself.
Organization filtering is applied on top of the scope. A user with all still sees only the workspace they have selected, for the record types that carry an Organization.
Modules define their own permissions. Tickets, leads, deals and expenses are ownership-scoped; the Budget add-on ships six ownership-scoped permissions covering view, add, edit, delete and approve, plus its settings.
Some capabilities are named permissions rather than scopes - for example the permissions that let a user assign a dispatch manager or act as one, the permission that allows a manager to pre-approve leave, and the permission that controls biometric device settings.
When a paid module is activated, its role permissions are inserted automatically, so newly enabled modules arrive with permission rows ready to configure.

Who Can Use This Feature?

Administrator

Set the scope of every permission for every role.
Review permissions after enabling a new add-on module.
Test the result by signing in as a user in that role.

This functionality is available only to Administrators. Users see the effect of their scope but cannot change it.

Prerequisites

Roles exist for the account. Every new Company is created with admin, employee and client.
The modules you want to control are enabled for the account.
You know who owns which records - assignment is what makes owned meaningful.

The Five Permission Scopes

Scope	What the user sees	Use it when
`none`	No records in the module. The module is effectively closed for this role.	The role has no business with the module at all.
`owned`	Only the records that belong to the user - the ones they own, such as records assigned to them.	A sales representative should work only their own leads, or an agent only their own tickets.
`added`	Only the records the user added themselves.	A user creates records for others to work, and should keep sight of what they entered.
`both`	Records the user owns and records the user added.	A team lead who both creates records and is assigned work of their own.
`all`	Every record in the module, subject to the selected Organization.	A manager, a finance controller or anyone who needs a complete view.

For Administrators

Step 1: Map roles to the records they need

What to do: Before touching the screen, write down each role and, for each module, whether that role needs their own records, the records they entered, both, everything, or nothing. Design this once for the organisation rather than adjusting it person by person.

What to verify: Every module a role can reach has a deliberate scope, including none where that is correct.

Step 2: Open roles and permissions

Go to: Settings → Roles & Permissions

What to do: Select the role you want to configure. Each module lists its permissions with a scope selector.

What to verify: The permissions listed match the modules that are enabled for your account.

Step 3: Set the scope for each permission

What to do: Set each permission to the scope you decided in Step 1, then Save. Set view, add, edit, delete and approve style permissions separately - a user may need to see everything but change only their own records.

What to verify: The saved scope is shown when you re-open the role.

Step 4: Test with a real user in that role

What to do: Sign in as a user who holds the role, or ask them to check. Open the module list and count the records. Because filtering is applied where records are fetched, the same limits appear in reports, the mobile app and any AI assistant access using a personal access token.

What to verify: The list contains exactly the records that role should see, and no more.

Step 5: Re-check after enabling a module

What to do: When you enable a new paid module, its role permissions are inserted automatically. Review them and set the scope you want rather than leaving the inserted defaults in place.

What to verify: The new module's permissions appear for every role and carry a deliberate scope.

Worked Example

Example: a sales team of five. The team is three representatives, one team leader and one sales manager. All five hold the employee role in name, but their access is shaped by scope. The Administrator configures the Leads and Deals permissions as follows.

Person	Leads - view scope	Leads - edit scope	Result
Representative	`owned`	`owned`	Sees and edits only the leads assigned to them. Another representative's leads are not in their list, board or reports.
Inside-sales coordinator	`added`	`added`	Enters leads for the representatives to work, and keeps visibility of everything they entered even after it is assigned to someone else.
Team leader	`both`	`owned`	Sees their own leads and the ones they entered, but can only change their own.
Sales manager	`all`	`all`	Sees and edits every lead in the selected Organization, and the pipeline totals reflect the whole team.

The support consequence is important: when a representative says a lead has "disappeared", the usual cause is that the lead was reassigned to a colleague. With owned, reassignment removes it from their view by design. If they must keep sight of it, the scope has to be both and they must be the person who added it, or the scope has to be all.

Expected Result

Each role has a deliberate scope for every permission. Users see only the records their scope allows, in every surface - lists, boards, dashboards, reports, the mobile app and AI assistant access - and Administrators can explain any visibility question by naming the role, the module and the scope.

Service / PSA lens

Service Organisation Context

Scoped permissions are how a firm gives a consultant their own engagements while a delivery head sees the whole portfolio. The same employee role set to owned on projects, tasks or tickets shows a consultant only the work assigned to them, while all gives the delivery head everything in the selected Organization. The client role and its scope are what let a client user reach the portal for their own documents without any internal visibility. Because filtering is applied where records are fetched, the same boundary holds in lists, reports and exports - worth knowing before time or billing data is reviewed. Sales, field and support teams in any business are configured the same way.

Important Notes

Menu names and their position can differ between product editions and can be customised for your account, so your sidebar may not match these paths exactly. Use Search or your Quick Access items if you cannot find a screen.
A menu layout cannot grant access. Hiding a feature from the sidebar does not remove permission, and showing it does not create permission. Permissions are the only access control.
Scope and Organization filtering are separate. A user with all still sees only the Organization they have selected, for the record types that carry one.
Permissions also govern automated access. An AI assistant or API client using a personal access token acts as that user and is limited by the same scopes, and write actions are re-checked against the user's own add and edit permission.
Add-on modules bring their own permissions. If a permission is missing, confirm the module is enabled for the account.
Test with a real user in the role. Reasoning about scopes on paper is not a substitute for checking a list.

Common Scenarios

Example: agents and their tickets. Support agents are given owned on tickets so each agent works their own queue, while the support lead is given all to monitor the whole backlog. Round-robin assignment then distributes new tickets, and each agent's list changes accordingly.

Example: budget approval. The Budget add-on is enabled, which inserts its permissions automatically. Project managers receive add and edit scopes for budgets, but only the finance lead is given the approve permission, so no one can approve their own numbers.

Example: expenses. Staff record their own expenses with a narrow scope, while an approver is given a wider scope so they can review expenses across employees.

Troubleshooting

Issue	Possible Cause	Resolution
A user opens a module and the list is empty	Scope is `owned` or `added` and nothing is assigned to or entered by them	Assign records to them, or widen the scope.
A record vanished from a user's list	The record was reassigned, and the user's scope is `owned`	This is intended behaviour. Widen the scope if continued visibility is required.
A report shows smaller totals for one user	The report respects the same scope as the list	Compare with a user who has `all`. Adjust scope if the user needs complete figures.
Two users in the same role see different records	Scope is per role, but ownership is per record; they own different records	Check who is assigned to the records in question.
A permission you expect is not listed	The module is an add-on and is not enabled for the account	Enable the module, then re-open the role. Permissions are inserted when the module is activated.
An AI assistant or API client cannot see a record	The token acts as its user and inherits that user's scope	Adjust the user's permission scope, or use a token issued by a user with the required scope.

Frequently Asked Questions

Is a permission a yes or no setting?

No. Each permission resolves to a scope - none, owned, added, both or all - and CrmLeaf filters which records the user sees using that scope.

What is the difference between `owned` and `added`?

owned covers the records that belong to the user, such as those assigned to them. added covers the records the user entered. both combines the two.

No. A menu layout can place, reorder, rename, group or hide a feature, but it can never grant or remove access. Use permissions.

Do these scopes apply to the mobile app?

Yes. The filtering happens where records are fetched, so the mobile app and API access follow the same scopes.

What happens to permissions when I enable a new module?

The module's role permissions are inserted automatically when it is activated. Review and set the scope you want.

Still need a hand?

Our support team answers on business days. Reference PLT-06 so we can jump straight in.

Contact support