Why deals disappear from visibility in Bitrix24
Deals disappear from the list not because of a glitch: a manager went on vacation, and his clients stopped opening for colleagues, while the department head, instead of his own, sees someone else's entire database.
In Bitrix24, this is how the discrepancy between the company structure and the permissions actually granted manifests.
The logic breaks at the junction of levels. A role in CRM opens access to a section, a department in the company structure defines "insiders" and "outsiders," and binding to a pipeline defines a specific set of deals.
When there is one sales pipeline for the entire business, and they try to solve deal access differentiation with a single role, the result is always extreme: either everyone can see it, or the person who needs it cannot.
The second source of errors is manual edits. You created a new department, transferred a manager, added a second pipeline — permissions are not inherited by default, and some deals end up without an assignee.
While a deal is linked to the previous owner, the new department does not see it, and the previous one continues to see a client who has already been transferred.
Separately, the database leaks through related entities: a contact or company remains open to everyone, although the deal is closed.
Even carefully configured Bitrix24 deal visibility will not save you if client cards are available to the entire department — exporting contacts takes minutes and leaves no traces.
Add to this the permissions cache, which does not update instantly, and "by eye" settings without a fixed policy — you get a system where no one is sure they are seeing the full picture. We will break down how this is addressed.
What changes in department operations after configuring permissions
After proper permission configuration, an employee sees in the list only those deals that are assigned to their department — the rest do not open even via a direct link to the card.
Visibility in Bitrix24 stops depending on colleagues' conscientiousness: the department's area of responsibility is set by role and pipeline binding, not by verbal agreements at stand-ups.
Transferring a deal between departments stops being a hand-to-hand passing of the card. The assignee changes, permissions are recalculated for the new division, and the deal history — comments, emails, calls, stage transitions — remains inside the card. The receiving department gets context, not a blank sheet with the client's name and phone number.
For a manager, daily work changes: pipeline control is built on their own data, without exports and manual reconciliation in spreadsheets.
They see at which stage deals get stuck, how many days a card sits without movement, and which managers have a successful close rate below the department average. The top level, meanwhile, gets a consolidated picture across all divisions.
Requests like "give me access to someone else's card" become a thing of the past: permissions are granted according to regulations, not through one-off requests in chat.
The scheme relies on user groups and roles, so a new employee only needs to be added to the department — and they immediately get the needed scope of visibility, while extra permissions are removed automatically when transferring between departments.
Ways to differentiate access to deals: comparison
In Bitrix24, deal visibility is determined by four independent layers: user role, binding to the department structure, pipeline settings, and local permissions for a specific record.
The layers overlap, and the strictest one does not always win — the result depends on the order of checks. That is why the base option is chosen first for the sales model, and the others are connected as refinements.
| Option | When it fits | Limitations |
|---|---|---|
| Local permissions per user | small team, one-off exceptions | configured manually; as headcount grows, support becomes ongoing work |
| User roles with deal permission | standard separation: manager sees their own, department head sees the department | only one role is assigned, complex combinations require duplicate roles |
| Department groups | several business lines with their own heads | the structure must be set up in advance; when an employee transfers, access is reassigned manually |
| Pipeline separation | different sales scenarios and independent teams | a deal is not transferred between pipelines without losing history and fields |
| Restriction by card field | need to hide part of the data from adjacent departments | does not work with all fields, some relationships remain visible |
In practice, the working option is a combination: roles cover standard access, department groups build the hierarchy of heads, the pipeline isolates business lines, and local permissions pick up exceptions.
The result must be checked from the perspective of each employee: a setting that looks correct in the interface may leave a deal visible through a related element or report.
Implementation order for access differentiation
Access differentiation starts not with settings, but with an inventory of what already works. On a live portal, you find overlapping groups, permissions granted "temporarily" and forgotten, and roles that duplicate each other.
Until this picture is fixed, editing pipelines breaks someone's scenario — and the department finds out about it from deals that have disappeared from view.
- Access rights audit. We capture the current matrix: which groups exist, who belongs to them, where permissions are granted directly and where they are inherited, which objects are open wider than intended. We record the discrepancy between the intent and the actual configuration.
- Role scheme. We describe roles by functions, not by people: department head, manager, adjacent division, leadership. For each — what they see, what they change, what they have no access to.
- Run-through of disputed cases. A deal went to another department, an employee changed roles, a client is handled by two divisions. We work this out before configuration, not after the first complaints.
- Configuration of pipelines and permissions. We bring groups, roles, and visibility rules to an agreed scheme. We formalize exceptions point by point and with a comment, so that later it is clear where they came from.
- Testing scenarios with real roles. We create test accounts for each role and go through the deal path end to end: creation, transfer, closing, report. Separately, we check that anything extra is not visible.
- Access regulations. We hand over a document: who creates an employee, how roles change upon transfer, who owns the role, and in what order access is expanded.
What we hand over: role schemes and visibility rules
The output is not a "configured portal" but a set of documents by which access can be checked, explained to a new employee, and handed over for support to another team.
Each artifact addresses its own question: who sees a deal, who has the right to move it to the next stage, to whom escalation goes when a client is "stuck" with another manager. Below is exactly what we hand over based on the results of the work.
- Access matrix — a "role → object → action" table: pipeline, stage, card fields, permission to read, edit, and export. From it, it unambiguously follows why an employee of an adjacent department does not see someone else's deal.
- Configured roles and groups — working profiles linked to departments, business lines, and territories, including temporary ones: vacation coverage, project team, access to a partner's pipeline.
- Visibility rules by pipeline — which stages are open to one's own department, what is available to the business line head, and what is closed until the deal is transferred for support.
- Escalation regulations — whom a manager writes to if a client is simultaneously handled by two employees, within what period a deal is returned to the common pool, and who confirms the removal of restrictions.
- Manager's instructions — how to include a new employee in the visibility scope, how to grant access to someone else's pipeline for the duration of a deal, and what to do in case of a rights conflict between two departments.
- Employee memo — what is visible in the card, why colleagues' deals are unavailable, and in what order to request an expansion.
- Configuration documentation — which rules are inherited from the group, which are set point by point, and a checklist of checks after every change in the org structure.
The package is assembled so that staffing changes do not turn into rebuilding access from scratch: a new role is added to the matrix, and the rest is inherited.
Case study: how departments stopped seeing other people's deals
What was the situation
The client was a wholesale company with three sales departments: retail, corporate segment, and tenders.
Everyone worked in a shared Bitrix24 pipeline, and access differentiation remained at the level of "everyone sees everyone": managers opened cards of other business lines, simultaneously called the same client, and created duplicates.
Deal transfer between departments was manual — a senior manager wrote in chat, the assignee was changed through settings, and the history of touches remained with the previous employee.
Managers spent up to an hour a day sorting out "who took it first," and about every fifth deal in a month was marked as disputed.
What was configured
Access was differentiated by division: each group received its own role, deals were linked to the assignee's department, and other people's cards were closed.
Business line heads retained consolidated access for their department, while the commercial director sees the entire picture.
Transfer between departments was moved to a separate stage: the deal leaves together with the history of touches, is assigned to a new assignee, and is not lost in correspondence, while a mandatory field with the reason for transfer shows how many deals go to the wrong place.
What changed
Metrics were taken before configuration and a month and a half after: the share of disputed deals fell from about 20% to 4%, transfer time decreased from 40 minutes of manual correspondence to a couple of minutes in the card, and duplicate calls for the same client almost disappeared.
Managers stopped being dispatchers — the hour a day spent on sorting things out returned to work with the pipeline and department plans.
How do permissions by department differ from permissions by pipeline?
In Bitrix24, deal visibility is set by two independent mechanisms: the department hierarchy and the binding of a pipeline to a business line.
They do not replace each other but add up — the final access is calculated by the intersection of rules, so a setting in one place often "disappears" because of a restriction in another.
Permissions by department rely on the company structure: a manager sees subordinates' deals, an employee sees only their own, and upon transfer access is recalculated automatically.
Permissions by pipeline work from the business line: access is granted to a department or group, and sales for a product are seen by those who work on it.
The schemes differ not only in effect but also in the support burden during changes.
| Criterion | Permissions by department | Permissions by pipeline |
|---|---|---|
| Basis | company structure, reporting line | binding of a pipeline to a business line |
| Effect | manager sees the entire department | access strictly by product |
| Reorganization | recalculated automatically | pipeline needs to be rebound |
| Support of the access scheme | low with a stable structure | higher: each pipeline has its own rule |
| Typical failure | deals "disappeared" upon transfer | conflict when departments are combined |
In practice, the scheme is assembled hybridly: base visibility — by departments, point pipelines — on top for specific business lines. Next, we break down how to describe it and maintain it during changes.
Frequently asked questions about configuring access to deals
Deal visibility in Bitrix24 is configured at the department level, not at the individual person level — hence most questions at acceptance.
Permission inheritance follows the company structure tree, so we check three places: role settings, the department binding in the employee card, and field access rules. Below are the doubts that come up most often.
An employee was transferred to another department, but they still see previous deals. Why?
Permissions are recalculated on every access to the list, but a previously granted role and personal exceptions may keep the previous set. We check the department change in the card, the set of roles, and whether the employee remained an assignee or observer in old deals.
The transfer of the deal itself does not alienate it — this is a separate rule for reassigning assignees; otherwise, access is pulled through them.
What do adjacent departments and managers see?
A manager sees their own department and nested divisions — the inheritance depth is set in the role, not "by default for everyone." Adjacent departments without a common parent do not see each other's deals; we grant shared access selectively, through a role with an extended scope or a separate deal group. This way, visibility remains manageable.
Does differentiation break reports and exports?
Reports and exports are subject to the same permissions as lists: the pipeline is calculated based on the deals the employee sees. A discrepancy in numbers between a manager and an employee is not an error but a consequence of the visibility scope.
We build the company-wide summary under a role with a broad scope, and we limit exports by the same rules so that data does not leave the perimeter.
Let's discuss the task: where to start with access differentiation
An accurate estimate of work is possible only based on the actual configuration, not on a "general outline" description.
Therefore, we start the analysis with the source data: which departments and pipelines exist, who should see a deal and at what stage, where exceptions are needed — vacation coverage, project teams from different departments, a manager's access to an adjacent business line.
What to send or show during the analysis:
- Division structure: departments, managers, reporting lines, who is listed in two teams.
- Access matrix by roles: which deals are visible — own, department, department with subdepartments, all.
- What happens to contacts, companies, and invoices at each access level.
- Current settings: roles and permissions in CRM, pipelines and stages, entity rules, what is closed by standard tools and what by customizations.
- Exception scenarios: deals with multiple participants, transfer of an employee between departments, freelance specialists and partners.
- External integrations: exchange with 1C, telephony, services that send or receive deal data.
- Scale: number of deals and users, availability of a copy for testing, who approves the final matrix.
Based on the analysis results, we return with an implementation plan: the order of settings and customizations, a scheme for testing permissions on a copy, approval points, and an estimate by scope of work and timelines. Separately, we discuss the risks and what is needed from your side at each stage.
Describe the task in the way that is convenient for you — we will return with a plan and estimate, and we will discuss disputed points on a call with the engineer who will lead the project.