The story repeats itself in every second company. A sales rep resigns calmly, without conflict, works out their two weeks honestly. A month later their former clients receive an offer from a competitor — and that is no coincidence. Before leaving, they exported the database to Excel, and nobody noticed, because there was nowhere to look.
Bitrix24 has almost everything needed to prevent this: a role model, a separate export permission, a change history, two-factor authentication. The problem is elsewhere — by default the portal is configured on the principle of "everyone sees everything", because that makes the launch faster. And that temporary mode stays forever.
Why "everyone here is family" is not a strategy
The objection always sounds the same: "we are a small team, I trust everyone". Trust has nothing to do with it. Access rights are not about distrusting a particular person — they are about the company owning an asset, and an asset needing a perimeter. The same argument does not stop you from locking the warehouse, even though you trust the storekeeper too.
The practical difference shows up the moment someone leaves. If the rep only ever saw their own clients and could not export data, their departure means handing over fifty deals. If they saw the entire database and had an "Export" button, their departure means a potential copy of your client base sitting with a competitor. The configuration is the same and takes half an hour; the difference in consequences is orders of magnitude.
There is a second layer people recall less often. A client base is personal data: names, phone numbers, e-mail addresses. A leak hits not only revenue but also compliance with the Law on Personal Data and Its Protection. How this works on our side is described in the privacy policy.
The role model: who sees what
The core tool is CRM roles, configured under CRM → More → Settings → CRM access permissions. They can be changed by a portal administrator or by an employee granted the right to change CRM settings. The free plan has no role model — it is part of the paid plans; the vendor revises the plan line-up from time to time, so check the current grid or ask us.
The logic is simple: you create a role ("Sales rep", "Head of department", "Accountant"), set an access level for each CRM entity — leads, deals, contacts, companies — and then assign the role to employees or departments. The levels are:
- Personal — only items where the employee is the assigned owner. The baseline for a sales rep.
- Department — plus items belonging to colleagues in the same department.
- Department and subdepartments — plus everything below in the structure. The level for a division head.
- Own teams and own teams and subordinate teams — the same idea, but by teams rather than by the org chart.
- All open — items with the "Available to everyone" option enabled.
- All employees — the entire database for that item type.
- Full access — no restrictions; the opposite pole is access denied entirely.
The level is set not in general but separately for each operation. This is exactly where the question of a stolen database is decided:
- Read — what the employee sees in the list and in the record.
- Add, edit, delete — what they can create and change.
- Export — downloading CRM items out of the system.
- Import — loading items into the system.
- Also: running automation rules, seeing the totals on kanban stages, moving items between stages, using a custom record layout.
What stock settings cover, and what they do not
To keep expectations realistic, here is an honest picture of the requests owners usually bring.
| What owners want to close | Stock feature | How it is done |
|---|---|---|
| Reps seeing other people's deals | Yes | A role with read level "Personal" |
| Exporting the base to Excel | Yes | Remove the "Export" permission from the role |
| Mass deletion of records | Yes | Remove "Delete", keep editing |
| Who changed which field and when | Partly | The "History" tab — system fields only |
| Hiding phone and e-mail from a rep | No | Restrict the field with permissions or use a Marketplace solution |
| Blocking logins from personal devices | Not in the cloud | Two-factor authentication reduces the risk of account takeover |
| Preventing a photo of the screen | No | There is no way — this is an organisational, not a technical perimeter |
A word on phone numbers, since this is the most common question. Bitrix24 has no stock toggle for "hide the number from the sales rep". There are two workarounds: close the field itself with access permissions for the relevant roles, or install a Marketplace solution that masks numbers in the record and in the mobile app. The second route is more robust but must be tested against your configuration: masking must not break telephony — the rep still needs one-click calling.
Change history: who touched the record
Lead, deal, contact and company records have a History tab. It shows the date, the author, the event type and a description: who moved the stage, who reassigned the owner, who edited a field. It is the first place to look when a deal "suddenly" turns into a loss or a client's owner changes.
An important nuance that is rarely written down: the stock history records changes to system fields. Custom fields you added yourself for your own processes are not included by default. If tracking edits in those fields is critical for you, that is a separate task solved by customisation or a Marketplace solution — and it should be planned in advance, not in the middle of an investigation.
Two-factor authentication
Access rights are pointless if someone else's account can simply be opened with a leaked password. Two-factor authentication is enabled under Settings → Security and can be turned on for the whole company at once: you set a deadline by which employees must configure it, after which logging in without the second factor is blocked. The confirmation arrives in an authenticator app, in the Bitrix24 mobile app, by SMS or by e-mail.
On higher plans two-factor authentication is mandatory — that is the vendor's policy, not our recommendation. On lower plans it is worth enabling yourself: it is the cheapest security measure in existence.
Offboarding: what to do in the first hour
The moment of resignation is not "sometime later" but the hour right after the conversation. The order is:
- Close access. An administrator dismisses the employee under Company → Employees. The person stays in the structure and their messages, tasks and files are kept, but they can no longer log in to the portal.
- Hand over the work. After dismissal, CRM deals and activities, tasks, mail and personal drive files are reassigned to the manager or a new owner.
- Check the history. Look through the "History" of records for mass edits or reassignments during the last days of employment.
- Change shared passwords. If the employee knew the credentials for mail, social accounts or the telecom operator's portal — change them, do not rely on hope.
- Revoke external access. The mobile app, open channels, connected services — everything that was tied to their account.
What no setting will ever cover
Here it is important to be honest, because the market promises otherwise. A sales rep by definition sees the clients they work with: they call them, write to them, travel to meetings. They can photograph the screen with a phone, copy numbers into a notebook, or simply memorise a dozen key accounts. No CRM in the world prevents that.
The legal perimeter: without it, settings work only halfway
Article 126 of the Civil Code of Kazakhstan protects official and commercial secrets when three conditions hold at once: the information has actual or potential commercial value because it is unknown to third parties, there is no free access to it on a lawful basis, and — crucially — the holder of the information takes measures to safeguard its confidentiality.
Read that last condition again. If the base is open to every employee and anyone can export it, you took no protective measures, which means there is nothing to defend in court either. Configured access rights are precisely those measures, and they are documented ones. But settings alone are not enough — you also need paperwork:
- A list of information constituting the company's trade secret — a specific list, not "all information".
- An NDA or a non-disclosure section in the employment contract, acknowledged by the employee in writing.
- A trade-secret regime policy: who is admitted to what, how access is granted, what happens on dismissal.
- A record of granted access — who was assigned which role and when.
Under the same article, persons who disclose a trade secret in breach of an employment or civil-law contract must compensate the damage caused. But you can only claim compensation if the perimeter was built in advance. After the leak it is too late to assemble it.
A working setup for a sales department
The configuration we most often implement in small and mid-sized Kazakhstani companies:
- Sales rep. Read — "Personal", edit — "Personal", add yes, delete no, export no. Sees their own clients, works with them, cannot export the base.
- Senior rep or head of sales. Read and edit — "Department", delete no, export no. Sees the team's work, but the base still cannot be exported.
- Executive. Read and edit across subdepartments, export at the owner's discretion. We usually leave it, with the understanding that this is a trusted person.
- Accountant. Access to deals and invoices to the extent their job requires, and the minimum necessary access to contacts.
- Administrator. Full access, two-factor authentication mandatory, a named account rather than a shared one.
This is then layered onto the org chart: the "department" and "subdepartments" levels work exactly as the company structure is built inside the portal. If the structure is nominal and everyone sits in one department, the role model gives you nothing. That is why order is restored from both sides at once — it is part of implementing Bitrix24, not a separate task.
Five mistakes we see during audits
- Everyone is an administrator. More common than you would think: it is convenient right up until somebody deletes a pipeline.
- Permissions configured, export forgotten. The most frustrating one: access was restricted, but the export button stayed available to everybody.
- A shared "sales" account. Three people work under it, and the change history is useless — you cannot tell who did what.
- An org chart on paper only. Everyone is in one department, so the "department" level effectively means "the whole company".
- Dismissed but not disabled. The person left a month ago, yet still has access to the portal and the mobile app.
