Configuring Access Rights in Bitrix24 CRM
When 30+ people from different departments work in a CRM, the absence of properly configured access rights becomes a security problem and an operational mess. Managers see each other's deals and accidentally edit them, team leads cannot quickly review a competing department's pipeline, and an analyst with administrator rights deletes records that should not be touched.
The permissions system in Bitrix24 CRM is built on roles with a permission matrix covering entities and operations. Correct configuration requires an understanding of several layers: CRM roles, record-level access, field restrictions, and visibility rules.
CRM Access Rights Architecture
CRM permissions are independent of general Bitrix24 permissions (with the exception of global administrators). The hierarchy:
- CRM roles — a set of permissions by operation type (view, create, edit, delete, export)
- Record-level access — own records / own department / all records
- Field permissions — hiding or locking specific fields on a card
- Pipeline and stage permissions — restricting access to specific pipelines
Configuration: CRM → Settings → Access Rights → Roles.
Configuring Roles
Minimum role set for a typical company:
| Role | Leads | Contacts | Deals | Companies | Reports |
|---|---|---|---|---|---|
| Manager | Own: R/W | Own + dept: R | Own: R/W | Own: R/W | None |
| Senior Manager | Dept: R/W | Dept: R/W | Dept: R/W | Dept: R/W | Dept |
| Head of Sales | All: R/W | All: R/W | All: R/W | All: R/W | All |
| Analyst | None | All: R | All: R | All: R | All |
Critical detail: the "delete" permission should only be granted to the Head of Sales and above. Deleted records without a recycle bin cannot be recovered (if the recycle bin is disabled in settings).
Department-Based Visibility Restrictions
The "own department" level works through the company structure in Bitrix24. If the structure is not populated, or a manager is not assigned to a department, they will see all records — even with a restricted role. This is a common mistake during initial configuration.
Verify the structure: Company → Company Structure. Every user must be assigned to a specific department, not left at the root level.
For multi-regional companies with multiple branches, use department groups via API:
// Get the user's department
$department = CIBlockSection::GetList(
[],
['UF_HEAD' => $userId],
false,
['ID', 'NAME']
);
Field-Level Permissions on Cards
Field visibility is configured separately from entity permissions: CRM → Settings → Access Rights → Field Rights. A field can be hidden entirely or made read-only for a specific role.
Typical use case: the "Deal margin" or "Cost price" field is visible only to the Head of Sales and the CFO; managers see only the total amount.
The restriction operates at the interface level. Via REST API, the field remains accessible if the user has a token with the necessary permissions. For serious financial data protection, additionally restrict permissions on REST applications.
Pipeline and Smart Process Permissions
Starting with Bitrix24 version 22.x, per-pipeline permissions became available for deals. A retail sales manager should not see the corporate client pipeline — this is configured in CRM → Deals → Pipeline Settings → Pipeline Access Rights.
Smart Processes (SPA) have their own permission matrix, independent of standard entities. Configuration is done via CRM → Smart Processes → [select] → Access Rights.
Auditing Permission Changes
Changes to access rights are logged in the b_event_log table with event types prefixed CRM_*. For regular auditing, export the log via REST:
CRest::call('log.get', [
'filter' => ['TYPE' => 'CRM_PERMISSIONS_CHANGED'],
'order' => ['DATE_CREATE' => 'DESC'],
'limit' => 50,
]);
Review the permissions matrix quarterly — especially after employee dismissals and role changes. Terminated users with active licenses remain a risk until their accounts are deactivated.