Turnkey company structure setup in Bitrix24

Setting Up the Bitrix24 Structure: Where the Org Structure Breaks

The org structure in Bitrix24 lives in three places at once: the tree of divisions and departments, positions in the employee card, and access rights that these departments grant to tasks, Disk, CRM, and HR sections.

As long as the company does not change, the linkage looks consistent — but a new business line, a manager transfer, or a merger of departments shakes it up.

Typical breakdown: divisions in the portal lag behind the company's real org structure by several HR decisions.

An employee is already running another business line, but access was granted manually and selectively; the former department still has rights to the pipeline, invoices, and documents that have long had nothing to do with it.

Then manual administration kicks in. New people are connected by hand, and during transfers and dismissals access is also revoked by hand — and some of it remains.

As a result, no one can say exactly who sees a particular deal, contract, or HR data: checking rights turns into going through cards one by one.

A one-time fix does not solve this: the structure changes faster than it can be redrawn in the portal, and rights are inherited from department to subdepartment and drag outdated connections along with them.

Setting up the Bitrix24 structure is needed not for a pretty diagram — the company's org structure becomes the single source of truth, and access rights by department are derived from it rather than assigned manually.

We break down how this is closed: from taking inventory of the department and position tree to the policy by which access appears and is revoked along with HR changes.

What Changes When the Portal Reflects the Real Org Structure

While the department hierarchy lives in a spreadsheet and the portal keeps the previous one, access is assembled manually: an engineer goes through parent divisions and nested groups, checks positions, and grants rights card by card.

A new employee takes several hours, and the same work is repeated with every transfer between departments. Each manual edit is a point where one level gets lost, and a person gets extra access to someone else's section.

When the tree of divisions and groups in Bitrix24 mirrors the real org structure, unified access rights are described once per department and inherited by nested groups.

Granting becomes adding an employee to a division, revocation becomes removing them from it: both operations take minutes and do not require going through cards.

A transfer between departments is handled by changing the division — old rights are removed with it, new ones come with the new one, so extra access does not accumulate.

Onboarding of new employees stops depending on reminders: the department and position themselves pull in a set of sections, tasks, and visibility rules, and the person reaches working mode on day one.

The class of errors 'access remained from a previous role' goes away at the level of the rights model rather than administrator discipline, and the number of access-related support requests drops.

Access separation becomes verifiable: for each department it is clear exactly what an employee sees, and an audit takes one pass through the tree instead of taking inventory of cards.

Maintaining Divisions and Roles: Manual Mapping or Synchronization

The org structure in the portal lives longer than any one-time import: employees move between departments, change positions, leave.

To keep divisions and roles from diverging from reality, a maintenance mode is chosen — manual mapping of divisions inside the portal, synchronization with an accounting system, or a hybrid scheme.

The difference shows up in the volume and dynamics of changes.

With a small staff and a couple of reshuffles per month, manual mode is cheaper in terms of administrator attention; with hundreds of employees and constant transfers, manual editing lags behind and breaks access rights. Below are the options that are actually chosen between.

In any mode, we fix in advance the criterion by which records are matched, how dismissed employees are handled — blocking instead of deletion preserves task history and correspondence — and who is responsible for manual edits. This is what keeps the structure up to date without daily intervention.

How Implementation Goes: From Audit to Portal Handover

The work sequence is the same for a company of any size: we record the actual state of the portal, design the scheme, test it on a copy, and only then transfer it to the production environment.

This removes the main risk — edits in a live org structure after which employees lose task visibility and request approval breaks in the middle of the route.

1. Org structure audit. We break down the current divisions, roles, reporting matrix, and how they are reflected in the portal now. We check against reality: where an employee is listed, whose requests they approve, who sees colleagues' tasks.
2. Design of the target scheme. We assemble the division tree and access rights tied to processes and reporting. Frequently changing nodes are marked separately so as not to hardwire them into a rigid hierarchy.
3. Transition plan. We determine the order: which divisions are moved first, who works under the old scheme until the end of the stage, and where manual headcount reconciliation will be needed.
4. Portal test environment. We deploy a copy, transfer the structure and rights there, and run scenarios: onboarding a newcomer, transfer between departments, request approval, access to shared documents.
5. Scenario validation. We work under real roles and look at where access is excessive and where it is blocked. All edits go to the copy — we do not touch the production portal until final confirmation.
6. Transfer and handover of policies. We transfer the approved scheme to the production portal and fix the rules: who creates an employee, how a transfer is approved, how rights are granted. We train administrators — the portal remains manageable without us.

Division Scheme, Roles, and Access Policies

The portal structure lives not in the interface but in documents by which it can be reproduced and handed over to another administrator without verbal explanations. Below is a set of artifacts that remain with the client after setting up the Bitrix24 structure.

• Division scheme — the hierarchy of departments with managers and reporting lines, reduced to the real org structure rather than the one that historically developed in the portal.
• Roles and user groups — a list of roles with their purpose, binding to divisions, separate rules for part-time employees and external contractors.
• Access rights matrix — rows are roles, columns are objects: disks, groups, tasks, calendars, documents. At the intersection is the access level, so excessive rights are visible before launch, not after an incident.
• Access policy — who approves granting, within what timeframe it is provided, what happens when an employee is transferred between departments and upon dismissal.
• Synchronization scheme with the accounting system — mapping of divisions and positions, exchange schedule, list of transferred fields, and rules for handling discrepancies.
• Portal administrator instructions — typical operations with step-by-step actions: creating a department, changing a manager, granting rights, checking the change log.
• Acceptance checklist — a set of checks by which the structure is considered operational: section visibility through each role's eyes, correctness of notifications, absence of 'dead' groups.

Documents are written in parallel with setup, not after it, so they describe the actual state of the portal. We check at acceptance: we log in under each role and verify what an employee sees and what they should not see.

Case Study: A Group of Companies with Several Legal Entities — One Org Structure

This implementation case study is about a group of companies with five legal entities: employees were managed in separate spreadsheets, each legal entity had its own file, its own department abbreviations, and its own reporting logic.

In Bitrix24, the org structure was assembled by hand, and it diverged from reality within a couple of weeks: when a person was transferred between legal entities, a duplicate appeared, and access rights remained from the previous position.

What It Was Like Before

Four unsynchronized directories, about 400 employees, 12% of records were duplicates. Access for a new person took two to three business days: the request went by email, each system was connected separately, and after dismissal some rights remained active.

What We Did and What Changed

We consolidated the directories into a single division tree, and made the legal entity a card attribute rather than a separate duplicating division. Access granting was moved to a policy: position → role → set of rights, without manually listing systems.

Access granting time dropped to 15 minutes in a typical case, manual edits decreased fivefold, and duplicates in the directory went to zero. Deactivation upon dismissal is done in one operation, and no overdue access remains. The scheme was fixed in the policy — a new legal entity is connected using the same template.

What to Do If the Company Structure Is Already Deployed and Changing?

The portal does not need to be stopped: a live org structure is changed with native Bitrix24 tools — through divisions and binding rights to them, rather than to specific people.

A department is added, renamed, or moved in the tree within minutes, and employee work is not interrupted.

The key principle is that access is granted to a role and division, and the employee is merely placed in them.

Then during a reorganization it is enough to move the person: rights to files, tasks, and deals are pulled in based on the new location, and accumulated history and documents remain tied to the department, not to the account.

The restructuring method is chosen based on the scale of changes.

Deleting a division with accumulated documents is not worth it — with frequent department changes, this is the fastest way to lose context. It is archived: access is closed for everyone except the responsible person, and working files are moved to the new location.

After each reorganization, we check three things: rights inheritance through the tree, visibility of files and tasks for new roles, and that access for departed employees has been revoked. This is a few hours of work instead of rebuilding the portal and regranting access manually.

Common Technical Questions About Org Structure and Access Rights

Transferring an existing scheme is more difficult than setting up from scratch: the company already has a policy, historical department names, and employee-to-manager bindings that cannot be lost.

We match current divisions, positions, and roles with portal entities, remove duplicates, and only then enable the exchange — otherwise the very first session creates a second set of departments.

What happens to rights when an employee is transferred or dismissed?

Access is granted to a department and position, not to a person, so a transfer between divisions changes the set of rights automatically, without manual editing.

Upon dismissal, the account is blocked by the exchange, and tasks and documents are reassigned to the manager — files do not remain in a closed profile.

How to connect external contractors and new legal entities?

A contractor is created as a user with external access: they see only assigned tasks, chats, and documents, but not the structure or department correspondence.

A new legal entity is added as a separate branch, and synchronization continues to work — including partially, for selected divisions.

Tell Us About the Portal — We Will Come Back with an Estimate and Work Plan

To come back with an estimate and work plan, it is enough for us to describe the current state of the portal and the task. Below is what is useful to include in your request; if some data is unknown, we will clarify it ourselves during the conversation and portal audit.

• How many employees and divisions there are, whether there are branches, combined positions, or matrix reporting.
• How the structure should look: who reports to whom, who sees data from adjacent departments, where closed sections are needed.
• Roles and access rights: which groups are needed, who approves requests, who administers the portal and configures directories.
• Which scenarios must work: approval routes, task assignment, knowledge base, HR processes.
• What the portal exchanges data with: 1C, email, telephony, external services.
• What exists now: a production portal with history, a test environment, or only an intention to launch.
• Constraints: desired launch timeframe, data protection requirements, procedure for introducing changes to the production system.

Then we proceed in order. We break down the current structure and access rights, show where groups are duplicated and connections between departments are broken, and build a model for your processes.

You receive an org structure scheme with roles, a map of portal sections, a turnkey implementation scope with stages, responsible parties, and the procedure for transferring data to the production environment.

Describe the task in whatever way is convenient: in a list, by email, or at a meeting. We will come back with an estimate and work plan showing what we do, in what sequence, and what will be needed from your side.