Visma.net ERP
About types of restriction groups
Restriction groups in Visma.net ERP provide additional flexibility to the configuration of access rights for workspaces and windows. (For details, see: User security - overview.) You can use restriction groups when users should have access to a window, but in this window they are allowed to see one set of entities and are not allowed to see another set of entities.
With different types of restriction groups, you can configure simple and complicated rules
of visibility for entities.
In this topic, you will find descriptions of the types of
restriction groups, the differences between the types, and usage examples.
In this topic, the restriction groups in the examples contain users and entities, but the same principles apply to groups that contain only entities.
When you add users and entities to a group, the system restricts the visibility of the
entities to the users.
When you add entities of two different types to the group and don't
add users, these entities can be used only with one another when users select values of
the entities on windows.
For example: If you add a general ledger account and subaccounts to the group,
and a user selects the included account on a window, only the included subaccounts are
available for selection.

Visma.net ERP provides two basic types of restriction groups, A and B.
Restriction groups of both types
can limit the visibility of system entities in a direct way (types A and B)
and an inverse way (types A inverse and B inverse).
The differences between
A and B and between A inverse and B inverse are in how these
groups work if the same entity is added to multiple groups.
You use groups of types A or B or groups with direct restriction when you need
to make entities visible to users within the group.
(For groups with only entities, the
direct restriction group includes entities that must be used together.)
The following
diagram shows how groups with direct restriction work.
In the diagram, you can see four
users (for example, accountants) and six entities (for example, general ledger accounts).
Initially, all
users can see all accounts.
Group 1 is defined to include Users С and D and Accounts 1, 2,
and 3.
These accounts are visible to Users С and D and hidden from Users Y and Z.
Group 2 is
defined to include Accounts 4, 5, and 6 and Users Y and Z.
Users Y and Z can see Accounts 4,
5, and 6, and Users С and D cannot see these accounts.
You use groups of types A inverse or B inverse or groups with inverse
restriction when you need to hide entities from a small number of users.
(For groups without
users, an inverse restriction group includes entities that may not be used together.)
See
the following diagram, which illustrates how groups with an inverse restriction work. Group
1 is defined to include Users С and D and Accounts 1, 2, and 3.
Accounts 1, 2, and 3 become
invisible to Users С and D and remain visible to users Y and Z.
Group 2 is defined to
include Accounts 4, 5, and 6 and Users Y and Z.
This hides Accounts 4, 5, and 6 from Users Y
and Z, but Users С and D still can see these accounts.
The final visibility for groups with
inverse restriction is the opposite of the final visibility for groups with direct
restriction.
The following table summarises the types of restriction groups and describes how the visibility of entities is affected if a particular entity belongs to multiple groups of the type.
Group type | Restriction | Description |
---|---|---|
A | Direct |
Makes entities included in the group visible to users who are also included in
the group. When a particular entity belongs to multiple groups of type A, if you want a user to see this entity in the system, you add the user to at least one of these groups. |
A inverse | Inverse |
Hides the entities included in the group from users who are also included in the
group. When a particular entity belongs to multiple groups of type A inverse, if you don't want a user to see this entity, you must include this user in each of these groups. If you include the user in only one of the groups, he or she will see the entity in the system. |
B | Direct |
Makes entities included in the group visible to users who are also included in
the group. When a particular entity belongs to multiple groups of type B, if you want a user to see this entity in the system, you need to include this user in each of these groups. |
B inverse | Inverse |
Hides the entities included in the group from users who are also included in the
group. When a particular entity belongs to multiple groups of type B inverse, if you don't want a user to see this entity in the system, you include the user in at least one of these groups. |

Problem statement
Suppose that as a system administrator, you have to configure the visibility of accounts to the appropriate users considering the following:
- There are four accountants in your organisation: User C, User D, User Y, and User Z.
- User M is the accounting manager who controls work of the accounting department.
- There are six accounts in the general ledger: Account 1, Account 2, Account 3, Account 4, Account 5, and Account 6.
- Users C and D are allowed to see Accounts 1, 2, and 3.
- Users Y and Z are allowed to see Accounts 4, 5, and 6.
- User M is allowed to see all accounts.
So Accounts 1, 2, and 3 should be visible to Users C, D, and M (and should be hidden from all other users), and Accounts 4, 5, and 6 should be visible to Users Y, Z, and M (and should be hidden from all other users).
You can use either of two solutions (described below) to configure the visibility of accounts to users.
Solution 1
To address the problem of Usage example 1, you can create three restriction groups of type A—Group 1, Group 2, and Group 3 (see the diagram below, including the user visibility shown in Final visibility (Group type A)):
- Group 1: In this group, you include Accounts 1, 2, and 3 and Users C and D.
- Group 2: In this group, you include Accounts 4, 5, and 6 and Users Y and Z.
- Group 3: In this group, you include User M and all six accounts.
If you were to use groups of type B instead of type A, all accounts would be hidden from the users included in Groups 1, 2, and 3.
See Final visibility (Group type B) in the diagram below.
(To make this approach work with groups of type B, you would need to include User M in Groups 1, 2, and 3.)Solution 2
As a second way to address the problem of Usage example 1, you can create two restriction groups of type A or B—Group 1 and Group 2 (see the following diagram):
- Group 1: In this group, you include Accounts 1, 2, and 3 and Users C and D.
- Group 2: In this group, you include Accounts 4, 5, and 6 and Users Y and Z.
- You include User M in both groups.

Problem statement
Suppose that as a system administrator, you have to configure the visibility of accounts to the appropriate users considering the following:
- There are four accountants: User C, User D, User Y, and User Z.
- There are six accounts in the general ledger: Account 1, Account 2, Account 3, Account 4, Account 5, and Account 6.
- User Y works with only one sensitive account, Account 1; User Y is not allowed to see
the following accounts:
Account 2, Account 3, Account 4, Account 5, and Account 6. - The other accountants work with all accounts except Account 1.
- Only accountants have access to the Finance module. (Thus, there is no need to hide accounts from other system users.)
Solution
To address the problem of Usage Example 2, you can create two restriction groups, Group 1 of type A or B, and Group 2 of type A inverse or B inverse.
(If you select type A for Group 1, you should select type A inverse for Group 2.
If you select type B for Group 1, you should select type B inverse for Group 2.)
These groups are defined as follows:
- Group 1: In this group, you include User Y and Account 1. (Other users will not see Account 1.)
- Group 2: In this group, you include User Y and Accounts 2 to 6. (User Y will not see these accounts.)

Problem statement
Suppose that as a system administrator, you have to configure the visibility of accounts to the appropriate users considering the following:
- There are four accountants in your organisation: User C, User D, User Y, and User Z.
- There are six accounts in the general ledger of your organisation:
Account 1, Account 2, Account 3, Account 4, Account 5, and Account 6. - Users С and D should work with all six accounts.
- User Y should work with Accounts 1, 2, and 3 but is not allowed to see Accounts 4, 5, and 6.
- User Z is a junior accountant, so this user is not allowed to see the accounts.
You can use either of two solutions (described below) to configure the visibility of accounts to users.
Solution 1
To address the problem of Usage Example 3, you can create two groups of type B inverse—Group 1 and Group 2 (shown in the diagram below, with the user visibility shown in Final visibility (Group type B inverse)):
- Group 1: In this group, you include User Y and Accounts 4, 5, and 6.
- Group 2: In this group, you add User Z and Accounts 1, 2, 3, 4, 5, and 6.
If you were to use groups of type A inverse instead of B inverse in this example, Accounts 4, 5, and 6 would be visible to all users because they are added in two restriction groups (see Final visibility (Group type A inverse) in the following diagram).
Solution 2
As a second way to address the problem of Usage example 3, you can create two groups of the A inverse or B inverse type—Group 1 and Group 2:
- Group 1: In this group, you include User Z and Accounts 1, 2, and 3.
- Group 2: In this group, you include Users Y and Z and Accounts 4, 5, and 6.

As you decide which type of restriction group best meets your security needs, consider the following recommendations:
- When you create multiple groups with entities of the same combination of types (for
example: suppose that you have two restriction groups that include users and customers),
use groups of the same basic type (either A or B).
(Otherwise, if you were to add the same entity to multiple groups of different types, the result may not be what you expect.) - To configure the required visibility of entities, you can combine direct and inverse restriction groups of the same basic type (either A or B), as was done in the solution of About types of restriction groups. Thus, you can combine groups of types A and A inverse, and groups of types B and B inverse.
- If you want to hide particular entities from the majority of users, include the entities and the users who should see the entities in a group with direct restriction (type A or B).
- If you want to hide particular entities from a small number of users, add the entities and the users who shouldn't see the entities to a group with inverse restriction (type A inverse or B inverse).
Parent topic:
Manage visibility with restriction groups - overview