Verified on release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4).
Your sales department has five managers. Each one should see in the database only their own counterparties and orders, not those of others. Setting up rights individually for each one is slow and unreliable — one gets forgotten, another gets too much. And tomorrow a new employee will start, and you'll have to do it all again. There's one right way — gather people into a user group and assign rights and restrictions to the whole group at once. A new manager arrives — add them to the group, and they instantly get the same set of rights as their colleagues. This is exactly what the "User Groups" catalog is for.
1. Purpose
The "User Groups" catalog combines information base users into named groups. A group is a "basket" into which you place people in order to later grant them rights in one action (through access group profiles) and configure which data exactly they see (record-level access restriction, RLS). This is a purely administrative object — it does not participate in accounting and does not generate postings.
2. Where to find it
Main path in the interface:
Master Data and Administration → section User and Rights Settings → Users. To the left of the user list, enable the display of groups (button More → User Groups) — there you'll find a tree of groups, and the Create Group button creates a new catalog element.
To open the full list of groups directly, insert a navigation link into 1C via Service → Go to navigation link (or Main menu → "All functions"):
e1cib/list/Справочник.ГруппыПользователей
Working with this catalog is only available to a user with an administrator role or the right to manage users. A regular manager will not see the group.
2a. How to find out your release
Main menu (☰ icon in the top left corner) → Help → About. In the window that opens: the "1C:Enterprise" line is the platform version, the line with the configuration name is the edition and release (for example, 3.4.5.21). Rely on this: the location of fields and buttons may differ between releases.
3. How to fill in
The group form is simple, but every field matters.
| Field | Why it's needed / what happens if filled incorrectly |
|---|---|
| Name (REQUIRED) | The name of the group, by which you search for it and assign rights. Cannot be saved empty. Write something meaningful ("Sales Managers," "Warehouse Storekeepers #1"), not "Group 1" — otherwise in six months you won't remember who it grants access to. |
| Group includes all users (flag) | A special mode. If enabled, all base users, including future ones, are automatically included in the group, and the "Members" table is not edited manually. Convenient for "to everyone" mailings. If this flag is set by mistake on a working group, everyone will get access to the data. |
| Members (tabular section, "User" column) | Who is included in the group. Add rows and select users from the "Users" catalog. Forget to add someone — they won't get the group's rights; add an extra person — they'll see other people's data. One user can belong to several groups at once. |
| Parent (hierarchy) | Groups can be nested within one another: "Sales Department" → "Wholesale Sales," "Retail Sales." Nesting helps distribute rights in large blocks. A group cannot be made its own parent. |
| Comment / Description | Your note: what the group is for, who is responsible. Doesn't affect anything, but saves time for your successor. |
Sequence of actions:
- Open the list of groups via the path from section 2.
- Click Create Group.
- Fill in Name — required.
- Decide: is this a group "for everyone" (set the flag) or a specific list of people (fill in Members).
- In Members, click Add, select users.
- Save and close.
Creating a group by itself does not grant any rights yet. For the group to be able to do anything, it needs to be linked to a rights profile: section User and Rights Settings → Access Groups → create an access group, select a Profile (for example, "Sales Manager") and specify your user group as a member.
4. Worked example
Task: three managers — Akhmetov, Kim, and Suleimenova — should see only their own counterparties, not the entire client base.
Step 1. Create the group. Name: Sales Managers. The "includes all" flag is unchecked. Add three users to "Members."
Step 2. Grant rights. In Access Groups, create an access group "Sales," profile — "Sales Manager," member — group Sales Managers. Now all three have received the same set of sales rights.
Step 3. Restrict visibility. In Master Data and Administration → User and Rights Settings → Restrict access at the record level, enable restrictions. Configure visibility for the group Sales Managers so that everyone sees only counterparties where they are specified as the responsible manager.
Result. Akhmetov logs into the base and sees in the counterparties list only his own clients. Kim and Suleimenova see theirs. A fourth manager, Ospanov, joins — you simply add him as a row to the "Members" of the group, and he instantly gets the same rights and the same visibility logic. Nothing else needs to be configured separately.
So where are the postings and amounts? There are none here, and there can't be. "User Groups" is an administrative catalog for access management. It does not generate accounting entries (neither on accounts 1210, 1330, 3310, nor VAT 16%), does not calculate individual income tax, pension contributions, or social tax, and does not affect amounts in documents. Distributing rights does not change accounting in any way — it only determines who sees and can do what in the program.
5. "Operation types" of the catalog
The catalog has no operation types like a document does, but it has three modes of use:
- Regular group with a list — you manually maintain "Members." The main working option.
- Group "includes all users" — the composition is formed automatically, the flag is enabled. For "to all employees" scenarios.
- Parent group (hierarchy node) — combines nested subgroups to distribute rights in larger blocks.
The predefined group "All Users" already exists in the base — it cannot be deleted, it always covers everyone.
6. What happens on save
When you click Save, the program saves the catalog element and its members. This object does not create any accounting postings, accumulation register movements, or electronic documents ESF and SNT — it has nothing to do with goods movement or taxes.
Practical effect of saving:
- The group becomes available for selection in Access Groups (for granting rights through a profile).
- The group can be used in record-level access restriction settings (RLS) — as an attribute by which the base decides who sees which data.
- Changing the composition immediately changes the rights of everyone in the group: remove a person — they lose access, add one — they gain it.
7. Printed forms
The "User Groups" catalog has no printed forms — this is not an accounting or tax document, there's nothing to print here. You can analyze rights distribution using administration service reports: User and Rights Settings → Reports → "Access Rights" and "User Information". There you can see which groups a user belongs to and what rights follow from that.
8. Common errors
"The 'Name' field is not filled in." You clicked "Save" with an empty name. Enter a meaningful group name and save.
"A group cannot include itself" / hierarchy loop. You're trying to make a group its own parent or create a nesting loop. Choose a different group in the "Parent" field or leave it empty.
"User is already a member of the group." The same person is listed twice in "Members." Remove the duplicate row — duplicates don't add anything.
"Insufficient rights to perform this operation on the data." You're not an administrator. Only a user with user management rights can modify groups — contact them.
Rights were added, but access still didn't appear. A classic case: the group was created and people added, but it wasn't linked to an Access Group and profile. The group by itself does not grant rights — you must assign it a profile in the "Access Groups" section.
The manager sees other people's data. Check whether the group has the "includes all users" flag set, and whether record-level access restriction is enabled at all — without it, RLS doesn't work.
9. FAQ
What's the difference between a "User Group" and an "Access Group"? A user group is a list of people ("who"). An access group links the list to a rights profile ("what can be done"). Rights are granted by the access group, while the user group simply defines its members.
Can one user belong to several groups? Yes. In this case rights are combined: the person gets everything granted by all their groups together.
What does the "Group includes all users" flag do? The group automatically covers all users of the base, including those added later. The manual "Members" list is not maintained in this case. Convenient for mailings and common rights "for everyone."
Can the "All Users" group be deleted? No. This is a predefined element, it is protected from deletion and marking for deletion.
How do I delete my group? Mark it for deletion (right-click → "Mark for deletion"), then run Administration → Delete marked objects. The program will not allow you to delete a group if it is still referenced by access groups — remove the references first.
Does a user group affect VAT, individual income tax, or amounts in documents? No. This is an access management tool. It does not affect the calculation of VAT (16% rate in Kazakhstan from 2026), individual income tax, pension contributions, social tax, or any amounts in documents.
I set up the group, but the employee still doesn't see the necessary documents. Why? Most likely, the group is not linked to a profile via "Access Groups," or the profile itself lacks rights to that section, or an enabled record-level restriction is cutting off the data. Check the whole chain: user → group → access group → profile.
What happens to rights if a person is removed from the group's membership? They will immediately lose all rights and data visibility that this group granted. If they still need the rights — add them to another group or assign them personally.
Can groups be nested within one another? Yes, the catalog is hierarchical. Nesting helps distribute rights in large blocks (department → subdepartments). The program prohibits circular nesting.
How can I find out what rights a user actually received? Open the user's card or the "Access Rights" report in the "User and Rights Settings" section — there you can see the final set of rights across all their groups.
10. Related objects
- "Users" catalog — the source of elements for the group's "Members"; a group without users is meaningless.
- Access Groups and Access Group Profiles — this is where the user group turns into real rights.
- Record-level access restriction (RLS) — the mechanism where the group is used as a data visibility criterion.
- External users / external user groups — a similar mechanism for counterparties and partners working in external services.
How to find out your release. Main menu → Help → About: it shows the 1C:Enterprise platform version and the configuration release.
This guide was prepared for "Trade Management for Kazakhstan," edition 3.4, release 3.4.5.21.