Setting up access rights in Bitrix24: where data diverges
The portal is deployed, funnels work, integrations are connected — but permissions remain in the "default" state. Any manager can open someone else's deal in full: amount, correspondence, attached files, and contacts. Internal "do not look" agreements are not documented anywhere, so they do not work.
This is noticed too late. The customer base gradually settles in personal exports: contacts are saved into a "for work" spreadsheet, records are forwarded to oneself, correspondence is copied.
When an employee leaves, the copy goes with the person, and from the logs it is no longer possible to reconstruct who took what — if logs were not configured in advance.
Configuring access rights in Bitrix24 solves this not "through the administrator's eyes," but through a role matrix and linkage to the org structure.
Deal visibility by department is set by hierarchy: a department head sees their team and nested departments, while an employee sees only their own records and group-wide ones. Export, mass actions, and fields with personal data are restricted separately.
CRM data segregation relies on least-privilege access: excessive rights are removed from an employee in a targeted way, rather than "just in case we forbid everyone."
The policy must survive changes: a new employee receives a role by department, a transfer to another department changes visibility without manual edits, and termination closes access together with the account. Next, we break down how this is configured and what we check at the input.
What the role model delivers: measurable effect
In Bitrix24, the role model turns access from a manual operation into a managed rule: an employee receives exactly the amount of data needed for work, and every change is recorded. The effect of access segregation is visible in specific metrics.
- Employee onboarding speed. Instead of manually granting rights for each section, a ready-made role template is assigned; access to deals, tasks, and files appears on the first working day, not after several days of approvals.
- Revocation of rights upon termination. One operation removes access across all sections at once, including exports and external integrations; the window in which a former employee retains access to the database is reduced to zero.
- Share of leak incidents. Visibility is limited to one's own deals and one's own department, and mass export is available only to roles with confirmed rights — some leaks are closed by configuration, not by policy.
- Eliminated class of access failures during transfers. When moving between departments, rights are rebuilt from the new role template: there is no "inherited" access to former clients.
- Audit of actions in CRM. The log answers who changed, deleted, or exported data; resolving a disputed situation takes minutes instead of searching by indirect signs.
- Separation of duties. A manager sees the funnel of their department but does not change settings; an administrator configures roles but does not manage deals.
The effect of access segregation can be checked in one pass: take standard roles, run the scenarios "new employee," "transfer," and "termination," and compare the result with the log. If at least one step requires manual editing, the model is not yet complete.
Access models: roles, groups, restrictions
In Bitrix24, the right to an object is granted not directly to a user but to a role, and the role inherits the context of the department and funnel.
This gives rise to four working schemes from which to choose when configuring access rights: overriding standard roles, custom roles down to the field level, a departmental scheme, and access for external contractors.
They can be combined freely, but each adds its own class of restrictions — and most often a leak occurs precisely at the junction of two schemes.
| Option | When it fits | Restrictions |
|---|---|---|
| Standard roles (administrator, manager, employee) | Small team, standard funnels, quick start | Rights come as a whole block: they cannot be narrowed to a single field or stage, and excess must be closed off by departments |
| Custom roles and field-level rights | Different functions within one department, sensitive fields — deal amount, cost, client contacts | The number of roles grows, and when a position changes, rights are reassigned manually; some system rights remain with standard roles |
| Department-based access scheme | Branches, matrix structure, distributed teams | The department hierarchy duplicates the org structure; when an employee is transferred, deal visibility changes — HR changes must be run through a check |
| Access for external contractors, accounting, agencies | External contractors work inside the portal | A separate role, entity-level restriction, and activity period are needed; otherwise the contractor sees more than necessary and the account lives longer than the project |
The common limitation of the model is inheritance: rights are composed of the role, department, and entity owner, so the resulting visibility is not obvious on paper.
We run the scheme on a test portal: logging in as each user type and checking records, fields, reports, and attachments. Segregation is verified before real data is opened, not after an incident.
Implementation order: from audit to handover of policies
Rights in Bitrix24 are composed of several layers: roles, workgroups, linkage to departments, and settings at the level of individual entities. Over time, personal exceptions, "temporary" accesses, and administrators no one remembers accumulate in them.
The work order is structured to capture the actual picture, design the scheme, and transfer it without stopping business processes.
- Access rights audit. We export actual roles, group memberships, deal and funnel owners, build an "employee — entity — access level" matrix, and note discrepancies with what should be according to policy.
- Scheme design. We tie roles to functions, not people: access is inherited from the department and position, and personal exceptions are minimized so a new employee receives the necessary rights on the first working day.
- Approval of disputed points. We review the found conflicts — overlapping areas, unnecessary administrators, access for terminated employees — with the responsible parties and document the decision in writing so the scheme is not rewritten from memory.
- Assembly on a test environment. We transfer the department structure, roles, and groups to a copy without affecting production data, and make sure rights inheritance works as intended.
- Access scenario testing. We run standard paths: a manager sees only their own clients, a department head sees the entire department, and adjacent units do not overlap. We separately check transfers between departments and access for external contractors.
- Transfer of settings to production. We perform it during a minimal-load window, record a rollback point, and compare the matrix before and after the transfer.
- Handover of policies. We provide the access matrix, instructions for granting and revoking rights, and the procedure for onboarding, transferring, and terminating an employee.
What you keep: role matrix, schemes, policies
Implementation ends not with the phrase "access has been configured" but with a set of documents your team uses to continue without us.
Each artifact is tied to the actual portal configuration: if a rule changes, the document changes too — otherwise, in a month no one will remember why the sales department has database export closed while the manager has it open.
- Role matrix — who in which funnels and at which stages can see, edit, and delete records; rights are granted by position and department, not by employee, so a new manager receives the necessary scope on the day of hire.
- Rights inheritance scheme — how group, department, and territory accesses are composed, where inheritance is overridden manually, and which settings break when a person is transferred to another department.
- Data access policy — rules for client personal data and exports: what is available to a manager, what is only for the department head, and which actions leave a trace in the log.
- Rights granting policy — request, approver, execution time, and mandatory revocation of access upon transfer or termination, with checklist-based control.
- CRM administrator guide — standard operations: adding an employee, changing the funnel owner, resolving an access conflict, and reading the event log.
- Review log — frequency of reconciliation, report on active rights, list of accesses granted outside roles, and accounts that should be closed.
The documents describe the logic of the rules, not names: when department composition changes, the matrix is not rewritten; it is enough to move the person between roles.
Such a kit addresses security service concerns and does not fall apart at the first change in the org structure.
Case study: separating visibility zones in a dealer network CRM
A dealer network with several branches ran sales in a single Bitrix24 database: deals, correspondence, and commercial terms were in a shared space. A manager saw deals from a neighboring city, and dealers saw each other's history of working with end clients.
Rights were granted manually, and after an employee was transferred to another branch, the old visibility zones followed them.
What it was like before the scheme change
Access was assembled from personal exceptions: for each new manager, the necessary funnels and client groups were opened separately.
More than a hundred granular rules accumulated in the system, and it was possible to understand why a specific deal was visible to the wrong people only from the change log.
Granting rights took an average of two working days, and requests to adjust access went to support almost daily.
What it became after
The scheme was rebuilt around departments: a deal inherits visibility from the responsible person's department and from the client linkage; the role is issued by template upon hiring and changes automatically upon transfer. Only about twenty granular rules remained — only for joint projects and the director's scope.
The time to grant rights decreased from two days to twenty minutes, and the flow of access requests fell from sixty per month to eight. There were no incidents of client base leakage between branches after implementation.
How does a CRM role differ from a portal user group?
Both entities manage access, but at different levels. A user group is responsible for belonging to a department: notifications, visibility of colleagues in the org structure, and rights to portal modules depend on it.
A role in Bitrix24 describes actions with data — reading, creating, modifying, deleting, and access to others' records.
The rules add up: an employee receives the union of rights from all their groups and roles, not the narrowest of them.
| What we compare | User group | CRM role |
|---|---|---|
| Purpose | department membership | actions with CRM objects |
| What it defines | notifications, portal modules | reading, modifying, deleting records |
| Inheritance | department rules apply in nested ones | assigned to a department, group, or person |
| Priority | rights are combined | broad right overrides narrow right |
| Risk | access grows when transferring between departments | excessive operations for a mass role |
Inheritance follows the org structure, so a role issued to a department immediately applies to all its employees. A narrow role will not restrict a person if they are placed in a group with broad rights — a common reason a manager sees others' deals.
Typical configuration mistakes: a role is granted personally instead of to a group with identical duties — upon transfer, access follows the employee; a group is expanded in the expectation that the role will restrict it; people forget that leaving a department does not remove a personal role.
We check not the settings but the fact: using a test account, we run the scenarios "own lead / colleague's lead / deal from another department" and compare with the rights matrix.
Therefore, we design segregation top-down: a "role × object × action" matrix, then the org structure and groups, and only then personal exceptions.
Technical concerns: 1C exchange, migration, external services
Rights in Bitrix24 do not live in isolation: roles intersect with 1C exchange, the mobile client, and telephony. Below are the concerns that most often come up before rebuilding an access scheme, and how we address them in practice.
Will the new role scheme break the 1C exchange?
The exchange runs under a service user, not a manager. We put its rights into a separate group with access to the entities involved in synchronization — other employees do not affect this environment.
Therefore, tightening rights for a department does not block the export of invoices and orders: the service account retains exactly the scope needed for the exchange.
What about the mobile app and calls?
Access in the mobile client is inherited from the main role — there is no need to maintain a second matrix. The exception is fields hidden by interface settings: they must be specified explicitly, otherwise the employee will see them from the phone.
Telephony is checked separately: the right to listen to recordings and access the call record is granted by its own group; otherwise, the manager loses the conversation history for their client.
We already have our own scheme configured. Will it have to be broken?
No. We take a current snapshot of rights, compare it with the target model, and transfer the difference in a targeted way: existing groups remain, and only the rules granting excessive access change.
Before applying, the scheme is tested on a test environment — we run exchange, calls, and mobile login scenarios, and only then enable it in production.
Let's discuss the task: where we start and what we prepare
To estimate the CRM work, a full audit is not needed — introductory information about how your departments and data are structured is enough.
We will gather it in one meeting: you describe the access segregation task, we ask clarifying questions, and immediately fix the scope of work.
What we need from you for the estimate:
- Organizational structure: departments, branches, external contractors, and part-time employees — the set of roles and object visibility levels depend on it.
- List of sensitive data: deals, contacts, documents, correspondence, call recordings — exactly what we are closing off and from whom.
- Current state: which roles are already configured, where employees see too much, whether there have been incidents or complaints about excessive access.
- Integration points: telephony, email, exchange with the accounting system, external portals — data leaks through them if rights do not account for service accounts.
- Access granting policy: who approves, how temporary rights extensions are documented, and who revokes them when the task is completed.
- Constraints on timing and order: whether rights can be changed in stages or a one-time switch is required.
Based on the discussion, we will return an estimate of the CRM work, a role scheme, and an implementation plan with stages, a verification procedure, and rollback points. Describe the task in general terms — we will come back with an estimate and a plan.