Configuring file access permissions in Bitrix24: a complete guide

Why Bitrix24 access permission setup breaks as the team grows

While a five-person department uses the portal, access control in the portal rests on manual rules: a folder was given a group, two managers had access added individually.

At twenty employees, exceptions pile up in the role matrix — they were set for a specific task and never removed. Folder permission inheritance stops being predictable: a child directory no longer repeats the parent's rules, but lives by its own mix of allowances and denials.

Next, accumulation kicks in. A permission granted to a deputy during vacation continues to work when the person has moved to another department.

Excess employee permissions are not visible in the interface — they dissolve among inherited ones, and checking "who sees what" turns into manually going through hundreds of records for each directory.

Errors in the role matrix are almost always of the same type: permission granted to a user directly instead of a group, a parent group has broader access than a group nested in it, an employee is in two groups with different levels for the same section.

The portal combines such rules differently than the administrator expected, and a file goes to someone it was not intended for — and this is discovered after the fact, not during setup.

The cost of such a breakdown is not only access to someone else's document.

An attempt to close something now risks cutting off access to those who need it, so permissions stop being touched at all: the matrix is fixed "as it turned out." Let's break down how this is addressed — from auditing actual permissions to a scheme of groups and folders that does not fall apart at the next hire.

Measurable effect: speed, stability, fewer failures

Granting access before putting things in order is a manual pass through the admin panel: find the user, determine the folder, set inherited permissions, don't forget adjacent sections.

A typical request took from twenty minutes to several hours, and the result depended on which administrator was on shift. With role templates, the same request is closed in a couple of minutes: the set of permissions is described by a policy, not by an employee's memory.

Revoking permissions is more expensive because access manages to spread through shared folders, external groups, and public links. When an employee leaves or transfers, permissions are removed from a single profile — personal access, group membership, external links.

Revocation time drops from days to tens of minutes, and no residual access remains with the former employee.

The share of manual operations decreases because typical requests leave the queue rather than being sped up inside it.

"Give access to the department folder" and "show who has permissions for contracts" are solved by a role and a report, not by a separate administrator task.

Permission checks usually reveal stable classes of failures: inherited permissions from a parent folder, because of which access is broader than intended; access through an external group after project closure; orphaned permissions during transfers between departments; indefinite public links to documents. Each class is closed by a rule, not by a one-time cleanup.

Before and after, control measurements are taken: time for granting and revoking in typical scenarios, number of manual edits per period, share of paths with an assigned role — they show that the rules continue to work after changes in the portal structure.

Comparison of access control schemes: groups, roles, inheritance

File permissions in Bitrix24 are not set by a single switch: they are made up of portal user groups, access levels for a specific folder, and inheritance from the parent directory.

Therefore, a seemingly identical request "close the department off from the rest" is solved differently — depending on the depth of the tree, the number of adjacent units, and the presence of external participants.

Below are working access control schemes: what each gives and where it starts to get in the way when the folder structure grows.

In practice, a combination works reliably: groups set the base, inheritance holds the framework, explicit denial is applied pointwise to HR and financial documents, and contractors are brought in as a separate group with a minimal set of permissions.

Such a scheme is auditable — every rule has a reason, and when connecting a new department you don't have to go through all folders manually.

Order of work: from audit to handover of policies

Permissions in Bitrix24 always have two layers: what is set in group and department cards, and what actually lies on folders after dozens of edits "for yesterday." Until these layers are reconciled, every edit turns into guessing: you closed access for one employee — you opened it for the neighboring department. Therefore, we do the work sequentially, recording the result at each step.

1. Audit of folder structure. We analyze the tree of directories and documents, find duplicates, "General" folders with accumulated inheritance, and sections where permissions are set pointwise on individual files. The output is a tree diagram with marks showing where inheritance works and where it breaks.

2. Map of actual access. We compare what is declared with reality: which departments, groups, and external participants see what and can change what. We consolidate discrepancies into a table "employee / role / folder / actual level."

3. Scheme design. We tie permissions to groups, not to people: one role — one set of folders and levels. We write inheritance explicitly, set denials at the top level so that new folders do not open by default.

4. Setup and exceptions. We transfer the scheme to real sections, close extra guest links, rework folders where permissions were handed out manually. We log every exception with its reason.

5. Testing on test roles. We create accounts for the number of roles and run scenarios: reading, uploading, editing, deleting, access via link, an employee leaving a department. Testing for termination and transfer is mandatory.

6. Handover of policies to support. We hand over the access map, group scheme, procedure for connecting a new department or folder, and a list of control checks. After that, support works by the document, not by a specific administrator's memory.

Role matrix, folder scheme, and work policies

Access permissions are configured once but live for years: they outlast changes of administrators, new contractors, and department reorganizations.

Therefore, we record the result not in a chat thread but in a set of artifacts — six months later they show why a department has no permissions for a specific section, and the setup can be repeated without sorting through past decisions.

• Role matrix — table "role → operations → scope": who reads, who uploads, who deletes, who manages access. It is agreed with department heads and serves as the standard when granting new permissions.
• Folder structure scheme — tree of sections with marks showing where permissions are inherited and where point exceptions are set. Inheritance instead of manual permissions for every object reduces the number of places where access can "leak."
• Permission granting policy — who submits a request, who approves, who grants, and for what period; separately — temporary access for contractors and the procedure for removing it.
• Support instructions — how to view current permissions, how to roll back an erroneous change, what to check when there is a complaint "I don't see the file."
• Settings change log — who, when, and what changed, linked to a request. It allows restoring the picture of a failure and understanding whose change closed access.
• Reconciliation policy — once a quarter, actual permissions are reconciled with the matrix: this is how access left over from dismissed employees and closed projects is found.
• Onboarding and offboarding procedure — a single set of actions so that access is granted and removed in one pass, without "forgotten" accounts.

Case: order in portal folders after department merger

After the merger of two departments in Bitrix24, two folder trees, two group schemes, and a layer of point exceptions that no one had revised remained. Permissions were granted directly to folders and employees, and inheritance from groups was constantly overridden.

A new person could not see half of the work documents, and access to HR sections remained with those who had long since changed roles.

Metrics before and after

First we assembled an inheritance map: for each folder, you can see which group the permission comes from and what overrides it.

Then consolidation of groups by roles — department, manager, external contractor — replaced personal exceptions, and the permission migration was run with a script on a test portal environment with reconciliation for each employee. Exceptions remained only where they are really needed: HR and contract sections.

For the customer, this is auditable order, not manual support: access is granted by changing a group, not by a support request, and once a quarter it reconciles with a report on who has what permissions.

Department mergers have stopped being a source of excess access, and a new employee gets the full set on the first day.

What is the difference between a folder-level denial and a file-level denial?

Permissions in Bitrix24 are stored not as a string for each employee, but as a record on the object itself — folder or file.

As long as an object has no record of its own, it inherits the rule of the nearest parent: you change access on a department root folder — the rule spreads through the entire subtree. This saves maintenance time, but it is precisely on inheritance that most holes appear.

A folder-level denial closes the folder itself. A file inside may have its own record — and it completely overrides inheritance rather than combining with it.

Therefore, an employee for whom the "Finance" folder is closed sometimes opens "Budget.xlsx" via a direct link from a chat: the file still had its own explicit access.

The second source of hidden exceptions is group permissions. If an employee belongs to several groups, the result is calculated by the union, and a denial in one group is overridden by an allow in another. An explicit denial works only where there is no longer any allow.

Hence the priority of analysis: the inheritance chain up to the root, then records on the object itself, then groups and external access. Traversing the tree shows objects where their own record diverges from the parent's — this is the list of exceptions for revision.

Common technical doubts and analysis of disputed situations

The doubts are usually the same: will the portal have to be stopped, what to do if files are outside Bitrix24, and how to hand over the project so that a new administrator can figure it out without us.

The debate should not be about "is it even possible," but about the order of work: inventory of current permissions, then changes on a test copy, and only then transfer to the production portal.

What should we do if files are in external storage?

Access is checked in two places: in the portal itself and in the storage. We configure both sides — we grant access by accounts and signed links so that the directory does not open entirely via a direct link.

How is the project handed over to the customer?

Together with the project, we hand over the permission scheme, group registry, list of responsible persons, and brief instructions for the administrator. We perform the work under a separate account, which we revoke after handover.

We have already granted extra permissions — is that critical?

It can be fixed: we take a map of current access, mark excessive permissions, and revoke them by groups rather than by individual user. After that — testing under a test account so that work scenarios do not break.

Let's discuss the task and come back with an estimate and work plan

To keep task analysis from dragging into a long chat, it is enough to send a minimal set of source data. From it, the scope of work and places where permission conflicts will occur are visible — not just the wording "we need to set up access to files."

• Portal structure scheme: which departments, workgroups, external contractors, and subsidiaries participate in document workflow.
• Current user roles and groups — an export or screenshots of the admin section: this is enough to see extra and inherited permissions.
• List of drives and folders indicating who should see, read, and edit what — by department or by specific people.
• Isolation requirements: who has access closed completely, who sees only their own section, and who sees consolidated documents.
• Description of related systems, if files are read from them: network drive, office suite, accounting systems.
• Constraints on the customer's side: internal security regulations, HR department requirements, the deadline by which the result is needed.

Next we analyze the task: compare current permissions with the target model, mark inherited allows that override your rules, and check whether anyone will lose access to their files after the changes.

As an output of the discussion, you receive an estimate of the scope of work, a phased implementation plan with rollback points, and a division of responsibility areas — what we do and what remains with the portal administrator.

Describe the task in free form — we will come back with an estimate and work plan.