Configuring Roles in Bitrix24 CRM
Roles in Bitrix24 CRM are not just a set of checkboxes in the interface. They represent the operational model that determines how the sales team interacts with data: who can see other people's deals, who can export the contact database, who is allowed to change the responsible person. Poorly designed roles lead either to excessive permissions ("everyone sees everything") or to a constant stream of requests to the administrator.
Role Structure in CRM
Each role defines permissions along two dimensions: operation type × visibility scope.
Operation types: read, add, modify, delete, export, import, view reports.
Visibility scopes:
-
--— no access -
A— own records only -
B— own records + subordinates' -
C— own department -
D— department + child departments -
X— all records
Important: scope B only works if the company structure has a correct manager–subordinate hierarchy. Without it, it behaves like A.
Designing Roles Around Business Processes
The most common mistake in role configuration is creating roles "by job title" instead of "by task". The title "sales manager" is one thing, but the actual tasks differ: handling inbound leads, managing existing accounts, working with a partner network. Each scenario requires a distinct set of permissions.
Recommended process:
- Describe the typical daily actions of each user group
- Determine the minimum set of permissions required for each action
- Group into roles by permission set, not by org chart position
For a company with separate sales channels (inbound leads + key accounts + partners), the optimal role structure is:
| Role | Leads | Deals | Contacts | Export |
|---|---|---|---|---|
| Lead Manager | A: RW | A: R | C: R | No |
| Account Manager | -- | A: RW | A: RW | No |
| Partner Manager | C: RW | C: RW | C: RW | No |
| Head of Sales | D: RW | D: RW | D: RW | D |
| Director | X: RW | X: RW | X: RW | X |
Assigning Roles and Multiple Roles
A single user can be assigned multiple roles — permissions are cumulative (the maximum permission from all roles applies). This is convenient during transition periods, but creates complexity during audits: it becomes unclear which role granted a specific permission.
Best practice: one role per user. If an expansion of permissions is needed, create a new role or use a temporary reassignment with logging.
Assigning a role via API (useful for automating onboarding):
// Add a user to a CRM role
CRest::call('crm.role.user.add', [
'roleId' => 5, // role ID
'userId' => 42, // user ID
]);
Roles for Non-Standard Scenarios
External agents and freelancers. Bitrix24 supports extranet users. Create a dedicated role for them with visibility scope A and no export — they see only their own records and cannot download the database.
Outsourced call center. Operators need to see all inbound leads but must not be able to change the responsible person or view deal financial data. Configuration: role with X:R on leads, restrict the ASSIGNED_BY_ID field from editing, hide the OPPORTUNITY field via field permissions.
Integration user for REST API. Create a dedicated robot user with the minimum permissions required for the integration only. Do not use real employee accounts for REST — when the employee leaves, the token will stop working.
Testing Roles
After configuration, verify roles using the "Log in as user" function (available to administrators). Walk through typical scenarios: create a lead, convert it to a deal, search for someone else's contact, attempt to export a list.
A common mistake: testers check only what the role prohibits and not what it allows. Make sure a user with the new role can complete all their work tasks without requesting administrator assistance.
Role change logs are written to b_event_log. Regular review helps catch unauthorized changes to the permission matrix.