Setting Up User Groups and Access Rights in 1C-Bitrix

1C-Bitrix user groups: where access rights break

Access rights in 1C-Bitrix are structured as the intersection of two independent mechanisms: user groups and access levels to specific information block sections.

A group defines a role at the module level, while inheritance down the site tree adds a second layer — and it is precisely at the junction of these layers that most failures occur.

A typical picture: an administrator creates a "Content Editors" group, grants it write access to an information block, but forgets that child sections inherit the parent's settings. As a result, the editor gains access to a service section that was intended to be closed.

The second common failure is a role conflict, when a user belongs to several groups at once.

Bitrix adds up permissions on the principle that "maximum rights win": if an employee remained in an old group with broad privileges and was added to a new one with reduced rights, they will continue to see more than they should.

Such "forgotten" memberships accumulate during staff turnover and surface during a security audit rather than during configuration.

The third scenario is a leak through public sections. The rights to the information block are configured correctly, but files and media reside in a public directory whose access is not restricted by the group.

A search engine crawler or a direct request serves the document bypassing all checks. Access control that does not cover the file storage creates a false sense of security.

Finally, user roles break during updates and migrations between environments: group settings are stored in the database, not in the repository, so a discrepancy between the test and production environments is almost inevitable.

Let's break down how to set up 1C-Bitrix user groups so that access rights do not diverge from reality.

What Proper Access Rights Configuration Delivers

A correctly structured access model in 1C-Bitrix is not a one-time setup but a managed framework where each employee has exactly the rights needed for their tasks.

1C-Bitrix user groups define roles, and their assignment determines the level of access to modules, information blocks, files, and the administrative area.

When this linkage is built deliberately rather than "as an afterthought," the effect is visible in measurable terms.

Employee onboarding accelerates dramatically: a new person simply needs to be added to the right group — access to work sections appears immediately, without manually ticking checkboxes and without waiting for "someone senior to set it up." Standard roles are described once and reused, so onboarding the tenth employee takes the same time as the first.

The class of incidents involving excessive rights is eliminated at the architecture level.

When rights are granted on the principle of least privilege rather than "just in case," the very possibility of accidentally deleting a section, modifying a template, or exporting the database disappears.

The issue of departed employees and contractors is addressed separately: access is revoked along with the role rather than left hanging forgotten.

Access auditing turns from a multi-day reconciliation into a quick procedure. Rights are grouped and inherited predictably, so an auditor can see who has access to what without manually going through hundreds of settings. This directly reduces risks: both reputational and those related to data integrity.

In total, the configuration delivers three measurable results — reduced onboarding time, elimination of the class of incidents involving excessive rights, and faster auditing. Let's break down how to build such a model for your project.

Approaches to access separation: comparing options

In Bitrix, access is built not by a single setting, but by a combination of four mechanisms: static user groups, module roles, permission inheritance across the section tree, and external authentication services.

The choice of model determines how much manual work will be required for each new employee or section.

How the models combine in practice

User groups set the baseline level: guest, authorized, editor, content administrator. Module roles refine this within a specific functionality — for example, access to an information block or to an online store section.

Permission inheritance from a parent section lets you avoid duplicating settings on every page: you change the policy at the top level and it applies to the entire subtree.

External authentication is connected when employees already live in a corporate directory, and there is no point in creating them manually in Bitrix.

A mixed model almost always wins: groups provide the framework, module roles cover functionality, inheritance removes routine work, and external login eliminates duplicate accounts. Below we break down how this is configured step by step.

Stages of implementation and configuration of user groups

Setting up user groups in 1C-Bitrix begins not with creating roles, but with taking inventory of what already exists: on a live project, permissions usually accumulated spontaneously, and half of the groups duplicate each other.

First, we capture the actual access matrix — who has access to which sections and modules, which permissions are inherited from parent groups, and which were granted on a case-by-case basis. Without this picture, any edit turns into guesswork.

1. Access audit. We export the current groups, their binding to sections, information blocks, modules, and files. We record discrepancies: an employee has left but the account is still active; a contractor was granted administrator access "temporarily"; content editing permissions are held by just about everyone.
2. Group design. We assemble roles based on real tasks: content manager, section editor, order manager, operator, administrator. Each group receives the minimum necessary set of permissions — the principle of least privilege instead of handing out broad access.
3. Permission configuration. We create groups and distribute permissions across sections, information blocks, and modules, and configure inheritance so as not to duplicate the same rule in ten places. We separately lock down service areas: settings, exchange with 1C, logs.
4. Access verification. We log in with test accounts for each role and check what is visible and what is closed. We separately review edge cases: access to other people's orders, data export, editing via API.
5. Handover of regulations. We provide the access matrix and the rules: how to onboard a new employee, how to grant and revoke permissions, who is responsible for changes. The regulation is more important than the configuration itself — without it, in six months the matrix will blur again.

After implementation, granting access takes minutes instead of correspondence with a developer, and the risk of a leak through a forgotten account goes away. Describe your task — we will come back with an estimate and a work plan.

What the client receives

The deliverable is not a set of "eyeballed" settings, but a documented access control system that can be handed over to another administrator or verified during an audit.

• Access matrix — a "role → section → action" table: which employees can see and change what. It is agreed with you before implementation, not after.
• Group configuration — created 1C-Bitrix user groups with permissions for modules, information blocks, files, and administrative sections tied to them. Every permission is justified by a role, and unnecessary ones are removed.
• Security policies — password rules, session timeouts, IP restrictions for administrative sections, and the procedure for granting permissions to new employees and revoking them upon termination.
• User instructions — short guides on typical actions: logging in, restoring access, and working with content within one's role.
• Permission review procedure — a periodic walkthrough: reconciling actual groups with the matrix, identifying "forgotten" accounts and permissions left over from past tasks.
• Role diagram — a visual map of groups and their intersections, so that when a new department is added, it is clear where to fit it in without rebuilding the entire model.
• Change log — a record of who was granted or revoked permissions and when, with the reason stated.

These artifacts address the main problem of access control — "set it and forget it." The matrix and the review procedure turn permissions from a one-time setup into a managed process: as the team grows or the contractor changes, access remains transparent, and knowledge that would otherwise be irrecoverable after an employee leaves does not.

Case Study: Eliminating Excessive Permissions in a Corporate Portal

A large corporate portal on 1C-Bitrix lived with a legacy: permissions were granted "on request," groups copied each other, and some employees were listed in several overlapping groups at once.

Formally, access existed, but no one could understand who saw what — neither the support service nor the portal owner themselves.

What It Was Before

The system had accumulated 47 user groups, 19 of which were duplicates with nearly identical permission sets. A new employee was onboarded to the portal over 2-3 days: access to sections, documents, and internal services had to be assembled manually.

Over the quarter, 6-8 access incidents were recorded — from excessive permissions for contractors to employees who retained access to their previous materials after being transferred to another department.

What Was Changed

We conducted an audit and consolidated the groups into a role-based model: 12 groups by function instead of 47 by person. Permissions were tied to roles rather than to specific employees — transferring between departments now changes a single binding instead of a dozen settings.

Onboarding was moved to a template: a new employee gets access by role on their first day instead of after several days of back-and-forth.

What It Became

The number of groups dropped from 47 to 12, and onboarding time went from 2-3 days to a few hours. Access incidents over the next quarter: zero versus 6-8 previously.

A separate effect is predictability: each section has an explicit permission owner, and any access expansion goes through a clear procedure rather than a personal arrangement.

We'll break down how to build such a model for your portal.

How do user groups differ from module roles?

User groups in 1C-Bitrix are the basic level of access control for the entire portal.

Each visitor upon logging in receives one or more groups, and it is these that determine what the person will see: a guest reads public pages, an authorized employee gets into a restricted section, an administrator manages settings.

Group permissions are set by modules and by specific elements — from "no access" to "full access" — and they are inherited according to the principle "everything is permitted that is not explicitly forbidden." This is a coarse but predictable setting: it answers the question "who can even enter this section at all."

Module roles are the next, more fine-grained layer. The "Information Blocks" module, the "Online Store" module, the "Document Flow" module maintain their own roles: catalog manager, order operator, approver.

Such a role describes not access to the site as a whole, but specific actions within a module — edit products but not change prices; see the orders of one's own department but not others'.

Roles rely on the same groups, but they allow separating employees with the same access level by areas of responsibility.

In practice, these mechanisms work in tandem, and they should not be confused. A group is responsible for the perimeter — whether a person is allowed into the administrative part and which modules are visible to them in principle.

A role refines behavior within the perimeter — what exactly they do there. If you try to solve everything with groups alone, their number grows avalanche-like: a separate group appears for every combination of permissions, and maintaining such a scheme becomes difficult.

If you rely only on roles without building groups, it is easy to end up with a hole: an employee with a broad role will accidentally end up where they should not be.

The practical rule is simple. Use groups to define large scenarios — guest, client, employee, administrator, partner. Use module roles to cover pinpoint tasks within these scenarios.

Then when adding a new employee, you assign them one group and one or two roles, rather than assembling access manually from dozens of checkboxes.

Such a scheme survives team growth and a change of contractor: the access logic remains readable rather than turning into a set of exceptions that no one dares to touch.

Common technical concerns when setting up access

Permission inheritance in 1C-Bitrix works on the principle of "the nearest rule overrides the more distant one": settings for a specific folder or information block take priority over the settings of the parent section, and those take priority over the root ones.

Because of this, a typical conflict looks like this: a user is added to a group with full access, but in practice sees an empty page, because at the section level there is a deny for another one of their groups.

Diagnostics takes time if you don't know that a deny is always stronger than an allow at the same nesting level.

Migrating groups is a separate headache. When moving between environments or after reorganizing the structure, permissions for files and sections do not transfer automatically: the group is created anew, and the bindings to objects are lost.

An access audit is needed precisely to catch such "orphaned" rules before they become a hole in security or a cause of employee complaints.

How do you transfer user groups to another site without losing permissions?

The standard export transfers only the groups themselves and their membership, but not the bindings to sections and information blocks. Permissions have to be reconfigured on the new site manually or with a script based on the access matrix.

Before migrating, it's worth taking a full export of the current rules — otherwise some access permissions will be lost unnoticed.

Can an unsuccessful permission change be rolled back?

Yes, if you save the access configuration in advance: an export of groups and bindings to sections and information blocks. Without such a copy, a rollback is done manually and takes hours.

We always record the initial state before making changes — this allows returning to a working scheme within minutes.

How do you tell that there are extra or outdated rules in the access permissions?

An audit is needed: reconciling the list of groups with the current company structure, finding groups without users, rules for deleted sections, and excessive permissions.

Such a review identifies points where access is broader than required and closes them without the risk of breaking working scenarios.

Let's discuss your access rights setup task

So that access rights setup doesn't turn into guessing game, we start with a short review of your configuration: which roles already exist, where rights were granted "just in case," and which 1C-Bitrix user groups actually work in production.

Describe the task in free form — we'll come back with an estimate and a work plan, without generic words.

What helps us quickly build an accurate picture:

• Which roles exist now: administrator, content manager, order manager, partner, external contractor — and who is responsible for what.
• Where it hurts: excessive rights for interns, access to other people's sections, manual granting for every new employee.
• How accounts are set up: local, via corporate directory, by invitations — the group scheme depends on this.
• Whether there is integration with 1C and external services, where rights for exchange and export need to be restricted separately.
• What about logs: whether it's necessary to record who and when changed content or settings.
• Growth plans: new directions, branches, contractors — so the group structure doesn't need to be rebuilt in a month.
• Constraints: security regulations, access segregation requirements, deadlines.

Next — a working call for 30-40 minutes: we review the scheme, clarify contentious points, and pin down what we're changing. After that, we send a work plan with stages, areas of responsibility, and rollout order, so that changes don't break current processes. Let's discuss the task — and you'll get a clear route instead of a set of scattered edits.