Restriction Groups Architecture

Hi All,

Today I want to share with you some technology information about how Acumatica Restriction groups works inside Acumatica.

Acumatica Restriction groups

For each group system assign one bit in the GroupMask Database column:
Group 1 – 0x8000 = 1000 0000 0000 0000
Group 2 – 0x4000 = 0100 0000 0000 0000
Group 3 – 0x2000 = 0010 0000 0000 0000
Group 4 – 0x1000 = 0001 0000 0000 0000
Group 5 – 0x0800 = 0000 1000 0000 0000
Group 6 – 0x0400 = 0000 0100 0000 0000
and so on

Here you can see that Acumatica numbers groups using bytes. Each group – one unique bit.
To maintain correct security rights fore new and removed groups Acumatica cannot reuse bits that are already used, that’s why you cannot delete existing groups.
Actually it can be changed/reused technically, but it require to update each record in database, that may be quite long on big databases.

When you assign some item to some group it actually sets the flags in the group masks for the item: Lets assume vendor belongs to group 3 and group 6, than mask will be
0010 0100 0000 0000 = 0x2400
Note that we have “1” exactly on position of group where this record belongs.

You can see exactly this configuration based on demo data:
User interface configurations:

And database:

Users are also belongs to groups by the same rule. Than system search for interceptions between groups to which user and entity belongs and than calculate calculate assess rights.
Also do not forget that there are different types of groups that can calculate interception and access rights differently.

Have a nice configuration.

4 Replies to “Restriction Groups Architecture”

  1. Does this mean we are limited to 16 Restriction Groups, or does this byte array continue to grow?

    (ie. 0x00008000 = 0000 0000 0000 0000 1000 0000 0000 0000)

Leave a Reply

Your email address will not be published. Required fields are marked *