Back to S200: SysAdmAdvanced

Lesson 8: Restriction Groups

Part 3: System Security

Acumatica ERP implements a role-based, task-oriented approach to security. System administrators assign roles to users and give the roles appropriate access rights to the system resources—such as modules, specific forms, form elements, and toolbar buttons—that the users need to perform their work tasks. For more information about user roles, please refer to S100 System Administration: Basic training guide. In addition to role-based access rights, you can use restriction groups to configure the security of information within the system. In this lesson, you will learn about ways of using restriction groups, types of restriction groups, operations that you can perform with the groups, and specific information about particular entities whose visibility you can control.

Lesson Objectives You will do the following:

• Learn about restriction groups
• Learn about the types of restriction groups, the difference between types
• Consider various usage scenarios of restriction groups
• Create a restriction group for customer accounts
• Create a restriction group that does not contain users
• Set up a default restriction group for a vendor class  | About Restrictions Groups | 88

About Restrictions Groups

Restriction groups in Acumatica ERP provide additional flexibility to the configuration of access rights for suites, modules, and forms. You can use restriction groups when users should have access to a form, but on this form they are allowed to see one set of entities and are not allowed to see another set of entities. A restriction group is a set of entities of two or more types that you define to achieve one of these goals:

• Control the visibility of sensitive data for employees of your organization. To do this, you include in a restriction group the entities for which you need to restrict the visibility, and the users who should or should not be able to view these entities.
• To relate entities to one another so that they are used only together on Acumatica ERP forms (or so that they cannot be used together). To do this, you include in a group only related entities and do not include users. System administrator can create and modify restriction groups in the Row-Level Security module which is the part of the Configuration suite.
  Managing Visibility with Restriction Groups To restrict employees’ visibility of sensitive data processed by using Acumatica ERP, you should create restriction groups with users. To understand how restriction groups with users are used, consider a typical case with restriction groups that include users and General Ledger (GL) accounts. Suppose that a role allows all its users to access all GL accounts, but for two groups of accounts, you want to provide visibility to only particular users. The diagram below demonstrates how restriction groups can address these security needs. You define Group 1 as a restriction group that includes only appropriate accountants (User C and User D) and accounts (1, 2, and 3). Similarly, you create Group 2, which includes User Y and User Z, as well as the accounts they should work with (4, 5, and 6).  | About Restrictions Groups | 89

Figure: Restriction groups for GL accounts and users

Among all users in the system, only User C and User D will see the first group of sensitive accounts (1, 2, and 3), and only User X and User Z will see the second group of sensitive accounts (4, 5, and 6). Users who are not assigned to any restriction group will not see the accounts associated with either group.

Restriction Groups Without Users If a restriction group does not include users, all users may view the entities that are members of the group (if their roles provide access to forms with these entities), but entities included in the group become related in a way that limits their use. For example, suppose that you create two groups with GL accounts and subaccounts as follows:

• Group 1 includes Account 1, Subaccount K, Subaccount L, and Subaccount M.
• Group 2 includes Account 2, Subaccount P, Subaccount Q, and Subaccount R.

For simplicity, suppose that there are no other accounts and subaccounts in the system. The result of these settings is the following:

• If a user selects Account 1 on an entry form, he or she will be able to select only Subaccount K, Subaccount L, or Subaccount M in a box with subaccounts. The subaccounts included in Group 2 will be hidden from the list.
• If the user selects Account 2, he or she will see Subaccount P, Subaccount Q, and Subaccount R in the box with subaccounts; the user will not see Subaccount K, Subaccount L, and Subaccount M.  | About Restrictions Groups | 90

Combinations of Restriction-Group Entities Acumatica ERP supports the a variety of scenarios of configuring the visibility of entities within the system. With the most common scenarios, you can create restriction groups that include the following system entities:

• Users and General Ledger (GL) accounts: With these restriction groups, if your organization has sensitive GL accounts, you can make these accounts visible to a limited number of employees.
• Users and subaccounts: As with groups that include users and GL accounts, you can limit the visibility of sensitive subaccounts to employees.
• Users and vendor accounts: You can define these restriction groups to make particular vendors visible in the system to only employees who work with these vendors.
• Users and customer accounts: With these restriction groups, you can make particular customers visible to only employees who work with these customers.
• Users and GL budget articles: With these restriction groups, you can limit the visibility of sensitive budget articles so that only particular users can see and work with these articles.
• Users and warehouses: You can create restriction groups to display a particular warehouse (or set of warehouses) for only employees who work with this warehouse (or this set of warehouses).
• Users and inventory items: You can define these restriction groups to reduce the number of items in the lists with inventory items, depending on the particular employee logged in to the system.
• Users and projects: You can define these restriction groups to configure the visibility of particular projects only to a responsible project team.
• Branches, GL accounts, and users: With these restriction groups, you can allow users to work with only branch-specific accounts.
• Branches, subaccounts, and users: You can set up these restriction groups so that the system displays to users only the branch-specific subaccounts.
• Branches and cash accounts: If there are multiple branches in your organization, with these restriction groups, you can allow users in each branch to work with only branch-specific cash accounts.
• GL Accounts and Subaccounts: If you have subaccounts that employees must use only with particular GL accounts, by defining these restriction groups, you can set up lists of available subaccounts for each GL account.  | Types of Restriction Groups | 91

Types of Restriction Groups

Acumatica ERP provides four types of restriction groups—A, B, 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. With different types of restriction groups, you can configure simple and complicated rules of visibility for entities.

Groups with Direct Restriction Restriction groups of A and B types limit the visibility of system entities in a direct way. You use groups of types A or B when you need to make entities visible to users within the group. Other users cannot view these entities. 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, GL 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.

Figure: Example of groups with direct restriction

When a particular entity belongs to multiple groups of the type (A or B), and you want a user to see this entity in the system:

• you add the user to at least one of these groups for type A.
• you need to include this user in each of these groups for type B.  | Types of Restriction Groups | 92

Groups with Inverse Restriction Restriction groups of A Inverse and B Inverse types limit the visibility of system entities in inverse way. You use groups of types A Inverse or B Inversewhen you need to hide entities from a small number of users. Users who are not assigned to this group can view and use the entities. For groups without users, an inverse restriction group includes entities that may not be used together. The following diagram 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.

Figure: Example of groups with inverse restriction

The difference between types A Inverse and B Inverse is the following:

• 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, this user will see the entity in the system.
• 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.

Recommendations for Selecting the Restriction Group Type As you decide which type of restriction group best meets your security needs, consider the following recommendations:  | Types of Restriction Groups | 93

• 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). 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).  | Usage Examples | 94

Usage Examples

In this topic, you will find the examples of restriction group configurations. In the examples below, the restriction groups 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 forms. For example, if you add a GL account and subaccounts to the group, and a user selects the included account on a form, only the included subaccounts are available for selection.

Usage Example 1 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 organization: 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 module: 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.)  | Usage Examples | 95

Figure: Example of groups with direct restriction and intersecting entities

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.  | Usage Examples | 96

Figure: Example of groups with direct restriction and no intersecting entities

Usage Example 2 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 module: 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 suite. (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 1: In this group, you include User Y and Account 1. (Other users will not see Account 1.)

The following diagram illustrates the proposed solution.  | Usage Examples | 97

Figure: Example of combined use of groups with direct and inverse restriction

Usage Example 3 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 organization: User C, User D, User Y, and User Z.
• There are six accounts in the General Ledger module of your organization: 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).  | Usage Examples | 98

Figure: Example of groups with inverse restriction and intersecting entities

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.

The following diagram illustrates Solution 2.  | Usage Examples | 99

Figure: Example of groups with an inverse restriction and no intersecting entities  | Step 8.1: Configuring Access to Customer Accounts | 100

Step 8.1: Configuring Access to Customer Accounts The Row-Level Security module of Acumatica ERP allows system administrators to create restriction groups for managing the visibility of different entities to users, or modify existing restriction groups by adding or removing users or entities. Depending on the entity type, the corresponding form of the Row-Level Security module should be used. For example, to restrict user access to customer accounts, you would use the Customer Access (AR102000) form. To view and create restriction groups containing vendor accounts, you would open the Vendor Access (AP102000) form. The following screenshot demonstrates the Row Level Security quick menu in the Modern UI.

Figure: Row Level Security quick menu

In the Classic UI, you have to open one of the forms in the Manage node of the Row-Level Security module, as shown in the screenshot below.  | Step 8.1: Configuring Access to Customer Accounts | 101

Figure: Row-Level Security module in Classic UI

In this step, you will create a restriction group such that the perry user does not have access to two customer accounts: C000000004 and C000000005. All other users should have access to all customer accounts. To achieve this goal, you will create a group of the A Inverse type and include the mentioned user and customers to this group. Perform the following instructions:

1. Launch the AcumaticaERP application instance by clicking Start > Acumatica > AcumaticaERP.
2. On the Welcome page of the instance, sign in to Company with the admin username and the 123 password.
3. Navigate to the Enable/Disable Features form (CS100000; Configuration > Common Settings > Licensing).
4. On the form toolbar, click Modify.
5. In the Monitoring & Automation group, select the Row-Level Securitycheck box, as shown in the following screenshot.  | Step 8.1: Configuring Access to Customer Accounts | 102
   Figure: Enabling Row-Level Security feature
6. On the toolbar, click Enable. The Row-Level Security module appears in the system, and now you are able to navigate to the forms of this module.
7. Open the Customer Access form (AR102000; Configuration > Row-Level Security > Manage). By using this form, you can create restriction groups for managing the visibility of customer accounts to users, or modify existing restriction groups by adding or removing users or customer accounts. You can also use the Restriction Groups by Customer (AR102010) form to manage the visibility of customer accounts to users, but you cannot create restriction groups on this form.
8. In the Group Name box, type Limit Access to Customers.
9. In the Group Type box, select A Inverse.
10. Leave the Active check box selected. If you clear this check box, this makes the group inactive, which means that restrictions imposed by the restriction group do not affect the visibility of entities to users.
11. On the Customers tab, select the check boxes next to C000000004 (KRK Consulting Service) and C000000005 (Wright Corner). This includes the selected customer accounts into the group, as you can see in the screenshot below.  | Step 8.1: Configuring Access to Customer Accounts | 103
    Figure: Customers added to restriction group
12. On the Users tab, select the check box next to perry (Perry, Edward), as shown in the screenshot below.
    Figure: User added to restriction group
13. On the toolbar, click Save.  | Step 8.1: Configuring Access to Customer Accounts | 104
14. Navigate to the Sales Profitability Analysis form (AR409000; Finance > Accounts Receivable > Explorer) and click the magnifier icon in the Customers box.
15. Verify that as admin user you are able to see all the customers in the dialog box that opens, including C000000004 (KRK Consulting Service) and C000000005 (Wright Corner), as shown in the screenshot below.
    Figure: All customers are visible for admin user
16. Navigate to the Users form (SM201010; Configuration > User Security > Manage) and in the Login box, select perry.
17. On the toolbar, click Log in as User.
18. Again navigate to the Sales Profitability Analysis form (AR409000) and click the magnifier icon in the Customers box.
19. Verify that as perry user you don't see the C000000004 (KRK Consulting Service) and C000000005 (Wright Corner) customers, as shown in the screenshot below.  | Step 8.1: Configuring Access to Customer Accounts | 105

Figure: Customers included into restriction group are invisible for perry user  | Step 8.2: Relating Accounts and Subaccounts | 106

Step 8.2: Relating Accounts and Subaccounts For forms in Acumatica ERP, you can specify which subaccounts can be used with only a particular account ; thus, the specified subaccounts will appear for selection only if that account is selected. This limitation will help users to avoid errors when they select accounts and subaccounts on forms. If you are using restriction groups to control the accounts and subaccounts that can be used together, you must create at least two groups and include all subaccounts in either of the groups. For example, suppose that you need to restrict visibility of subaccounts for only one account. To solve this task, you create two restriction groups. In the first group with direct restriction, you include a GL account and the list of subaccounts that should be related to this account. In the second group with inverse restriction, you include the same account and subaccounts that should not be displayed after users select this account. As a result, when users select the account on a form, they will see only one of the subaccounts included in the first group. In this step, you will create two restriction groups: one of type A, and another of type A Inverse. You will include the 130000 acount into both groups. You will also include one of subaccounts existing in the system (000-00-00) to the first group, and all other existing subaccounts into the second group. The result of such configuration is the following: when you select the 130000 account, only 000-00-00 can be selected as subaccount. Perform the following instructions:

1. Launch the AcumaticaERP application instance by clicking Start > Acumatica > AcumaticaERP.
2. On the Welcome page of the instance, sign in to Company with the admin username and the 123 password.
3. Navigate to the Segmented Keys form (CS202000; Configuration > Common Settings > Segmented Keys).
4. In the Segmented Key ID box, select SUBACCOUNT.
5. In the Lookup Mode box, select By Segmented Key and save the changes, as shown in the screenshot below. In this mode, a system user enters the entire identifier. When the user is typing the identifier on the data entry form, the system displays the list of existing identifiers. The user can select one of the existing values from the list. Selecting this mode also makes it possible to view the list of subaccounts defined in the system and select those to be included in the restriction group.

      Figure: Lookup mode for subaccounts
   

 | Step 8.2: Relating Accounts and Subaccounts | 107

        If the By Segment: All Avail. Segment Values lookup mode is selected on the Segmented Keys
        (CS202000) form for the SUBACCOUNT segmented key (that is, if the users of your Acumatica ERP
        instance enter subaccounts by segments on forms), you will manage the security of subaccount
        segments instead of entire subaccounts. In this case, you will need to add to a restriction group all
        subaccount segments that form a subaccount whose visibility should be restricted.

6. Navigate to the GL Account Access form (GL104000; Configuration > Row-Level Security > Manage). By using this form, you can create restriction groups for managing the visibility of accounts and subaccounts to users, or modify existing restriction groups by adding or removing users, accounts, or subaccounts. You can also use the Restriction Groups by GL Account (GL104020) and Restriction Groups by Subaccount (GL104030) forms to manage the visibility of accounts and subaccounts to users, but you cannot create restriction groups on these forms. 7. In the Group Name box, type Limit Access to Subaccounts. 8. In the Description box, type Restrict visibility of subaccounts 9. In the Group Type box, select A. 10. Leave the Active check box selected. If you clear this check box, this makes the group inactive, which means that restrictions imposed by the restriction group do not affect the visibility of entities to users. 11. On the Accounts tab, select the check box next to 130000 (Merchendise Inventory). This includes the selected accounts into the restriction group. 12. On the Subaccounts tab, select the check box next to 000-00-00 (Non-specific), as shown in the screenshot below.

 Figure: Subaccount added to group

13. On the toolbar, click Save. The first restriction group is created. Now you will create the second group of the inverse type.  | Step 8.2: Relating Accounts and Subaccounts | 108 14. On the form toolbar, click Add New Record. 15. In the Group Name box, type Limit Access to Subaccounts Inverse. 16. In the Description box, type Restrict visibility of subaccounts 17. In the Group Type box, select A Inverse. 18. Leave the Active check box selected. 19. On the toolbar, click Save. The group is created; you can populate it by using the Restriction Groups by GL Account (GL104020) and Restriction Groups by Subaccount (GL104030) forms. 20. Open the Restriction Groups by GL Account form (GL104020; Configuration > Row-Level Security > Explore). 21. In the Account box, select 130000. You can see that this account has been already added to the Limit Access to Subaccounts group of type A. 22. Select the checkbox next to the Limit Access to Subaccounts Inverse group to include the account into both of groups, as shown in the screenshot below.

Figure: Adding GL account into the second restriction group

23. On the toolbar, click Save. 24. Open the Restriction Groups by Subaccount form (GL104030; Configuration > Row-Level Security > Explore). 25. In the Subaccount box, select 000-00-00 and verify that this subaccount is included in the direct restriction group and not included to inverse restriction group.  | Step 8.2: Relating Accounts and Subaccounts | 109

Figure: Checking presence of subaccount in restriction groups

26. Click the Go to Next Record button, and for all other subaccounts, add them to the Limit Access to Subaccounts Inverse group and save the changes. When you complete, the 000-00-00 will be in the Limit Access to Subaccounts group, and all other subaccounts will be in the Limit Access to Subaccounts Inverse group. Now you can check how it works. 27. Navigate to the Chart of Accounts form (GL202500; Finance > General Ledger > Manage) and verify that the Secured check box is selected for the 130000 account, as shown in the following screenshot. This check box indicates (if selected) that the account is included in one or more restriction groups.

Figure: Chart of accounts

28. Navigate to the Subaccounts form (GL203000; Finance > General Ledger > Manage) and verify that the Secured check box is selected for all subaccounts, as shown in the following screenshot.  | Step 8.2: Relating Accounts and Subaccounts | 110

Figure: List of subaccounts

29. Navigate to the Inventory Preferences form (IN101000; Distribution > Inventory > Configuration > Setup). Now the 139000 account is selected in the In-Transit Account box. 30. Click the magnifier icon in the In-Transit Sub. box and verify that the lookup window contains a number of different subaccounts. 31. In the In-Transit Account, select 130000. 32. Verify that in the In-Transit Sub. box, the 000-00-00 has been automatically selected, and no other account cannot be selected in the lookup window, as you can see in the screenshot below.

Figure: Only 000-00-00 can be used together with already selected account

 | Step 8.3: Setting Up Default Restriction Groups | 111

Step 8.3: Setting Up Default Restriction Groups Sometimes you may need to restrict user access to numerous similar entities, such as vendors of specific vendor classes, or customers of specific customer classes. To ease the addition of new vendors and customers to restriction groups, you can specify a default restriction group for a vendor or customer class, so that vendors and customers of the selected class will be included in the restriction group automatically. For example, suppose that you have a class of vendors, and only the senior accountant is allowed to process documents from this vendor class. To configure the visibility of the vendor class, you do the following:

1. Configure a restriction group with direct restriction: a. Create a group of type A or B. b. Add the user account of the senior accountant to this group. c. Optionally, add vendors to this group.
2. Specify the created group as specify a default restriction group for a vendor class on the Vendor Classes (AP201000) form. With this setting, all new vendors of the class will be automatically added to the restriction group.
3. Apply restriction settings to all vendors of the class. Instead of including every vendor of the class in this restriction group manually, you can save time and click the Apply Restriction Settings to All Vendors on the Vendor Classes (AP201000) form. In the same way, you can create a restriction group for customers on the Customer Access (AR102000) form, and then select the group as default for a customer class on the Customer Classes (AR201000) form. You can also include all customers of the class in the specified group and exclude them from the group previously specified as the default one. In this step, you will create a restriction group for vendors, add a user account of Joseph Becher (suppose, he is a senior accountant) to this group and then specify this restriction group as default for the DEFAULT vendor class and apply restriction settings to all vendors of this class. Perform the following instructions:
4. Launch the AcumaticaERP application instance by clicking Start > Acumatica > AcumaticaERP.
5. On the Welcome page of the instance, sign in to Company with the admin username and the 123 password.
6. Navigate to the Vendor Access form (AP102000; Configuration > Row-Level Security > Manage).
7. In the Group Name box, type Group for Senior Accountant.
8. In the Group Type box, select A.
9. Leave the Active check box selected.
10. On the Users tab, select the check box next to becher (Becher, Joseph). This includes the selected user account into the restriction group.
11. Save the changes, as shown in the following screenshot.  | Step 8.3: Setting Up Default Restriction Groups | 112
    Figure: User account added to group
12. Navigate to the Vendor Classes form (AP201000; Finance > Accounts Payable > Configuration > Setup).
13. In the Class ID box, select DEFAULT.
14. On the General Settings tab, in the Default Restriction Group box, select Group for Senior Accountant.
15. Save the changes, as shown in the following screenshot. Now all newly created vendors of the DEFAULT class will be automatically added to the selected restriction group.
    Figure: Default restriction group selected
16. On the form toolbar, click Apply Restriction Settings to All Vendors.  | Step 8.3: Setting Up Default Restriction Groups | 113
    This adds all vendors of the class to the default restriction group. To exclude vendors of the class from a restriction group they were members of, on the Vendor Classes form, clear the field for the default restriction group and click Apply Restriction Settings to All Vendors.
17. Navigate to the Vendor Access form (AP102000; Configuration > Row-Level Security > Manage) and in the Group Name box, select Group for Senior Accountant.
18. Verify that on the Vendors tab, all vendors belonging to the DEFAULT class (that is entities with IDs from V000000001 to V000000092) have the selected check boxes. This means they are included to the group. Now you can check that other users do not have access to vendors added to the group. The beauvoir (Beauvoir, Layla) user exists in the system and has the same roles as becher (Becher, Joseph), but she has not been added to the restriction group that now includes all vendors.
19. Navigate to the Users form (SM201010; Configuration > User Security > Manage) and in the Login box, select beauvoir.
20. Navigate to the Vendors form (AP303000; Finance > Accounts Payable > Manage).
21. Verify that no vendors are shown to Layla Beauvoir by clicking Go to Previous Record and Go to Next Record buttons.
22. Sign out and sign in as admin.
23. Navigate to the Users form (SM201010) and in the Login box, select becher.
24. Open the Vendors form (AP303000) and verify that for Joseph Becher, all vendors are displayed, as you can see in the following screenshot.
    Figure: Becher can access any vendor  | Additional Information | 114

Additional Information

The following concepts are outside of the scope of this course but may be useful to some readers. You can use the links below to get additional information.

Vendor Security If your organization buys goods and services from external organizations, your accountants manage vendors’ information and process documents. If your organization works with more than 10 vendors, accountants may work with particular vendors only. In this case, the accountants who do not work with these vendors should not see them in the system for security reasons and to avoid entry errors. You can use restriction groups to make vendors visible to only accountants who work with these vendors in the system. For more information, see Vendor Security in User Guide.

Customer Security If your organization sells goods and provides services to customers, you may have a great deal of customer-related information stored in Acumatica ERP. When the employees of your organization create documents for customers, they have to select the required customer from the full list of customers. If certain employees work with only very important customers, and other employees are not allowed to see these customers in the system for security reasons, you can create restriction groups to manage the visibility of your customers to users of Acumatica ERP. For more information, see Customer Security in User Guide.

Security of GL Budget Articles In Acumatica ERP, organizations implement general access restrictions by assigning roles to users of the system. The roles assigned to users allow them to access the needed resources to perform specific tasks required for their jobs. If a role allows a user to view or edit General Ledger (GL) budget articles, the user can view all the articles, including those that might be sensitive. By using restriction groups, you can limit the visibility of sensitive budget articles so that only particular users can see and work with these articles. For more information, see Security of GL Budget Articles in User Guide.

Project Security Many organizations use projects to achieve their business objectives efficiently. An organization may have multiple projects in progress. By limiting users’ access to and visibility of information about particular projects and related transactions, managers can properly organize the work on each project. In Acumatica ERP, you can use roles to provide access to forms according to employees’ responsibilities and restriction groups to configure the visibility of particular projects only to a responsible team. For more information, see Project Security in User Guide.

Account and Subaccount Security In Acumatica ERP, you can control which users will use particular General Ledger (GL) accounts and subaccounts. To configure the security of GL accounts and subaccounts, you can use a combination of user roles and restriction groups. By using user roles, you can configure the access of users to branches and to all branch-specific accounts and subaccounts. With restriction groups, you can set up the visibility of particular accounts and subaccounts within branches and for certain users, and you can limit the use of subaccounts with particular accounts. For more information, see Account and Subaccount Security in User Guide.

Security of Cash Accounts Cash is a company’s most liquid asset, which is why an organization must have adequate controls to secure it. In Acumatica ERP, you can control which users can view which particular cash accounts. For more information, see Security of Cash Accounts in User Guide.  | Lesson Summary | 115

Lesson Summary

In this lesson, you learned about restriction groups in Acumatica ERP. Review Questions:

• What are restriction groups in Acumatica ERP and how they differ from roles?
• In brief, what are the types of restriction groups available in Acumatica ERP?
• What are the entities that are controlled by restriction groups?
• Is it possible to create a restriction group without users?
• How would you add a large number of customer or vendor accounts to a restriction group?  | Lesson 9: Inventory and Warehouse Security | 116