Migrate from Data Security Policies to Access Group Rules

You can provide users with access to sales and service data using data security policies, access group rules, or a combination of both.

If you started using the sales application before release 22B, the predefined job roles and any custom job roles you create provide users with data access using data security policies. But you can supplement or refine the access each type of role provides using either data security policies or access groups rules.

You can also configure custom job roles so that the data access they provide is achieved using only, or primarily, access group rules. For example, you might decide that you want users assigned a custom sales representative job role to access object records using access group rules. To do this, you deactivate the data security policies assigned to the custom job role, then assign access group rules that provide the same access to the system access group generated for the custom role.

Note: Data security policies for the predefined job roles are locked and can't be deactivated.

There are five steps in the process of migrating a custom role to provide data access primarily through access group rules:

Identify the Data Security Policies to Deactivate
Identify the Access Group Rules that Correspond to Data Security Policies
Add Rules to the Access Group Generated for the Custom Role
Deactivate Data Security Policies
Verify User Access to Data

Tip: It's a good idea to devise a few use-cases you can use to compare users data access before and after the migration process. That way, you can identify any gaps and avoid potential user access issues.

Identify the Data Security Policies to Deactivate

The first step in the process of migrating a custom job role to use access group rule data access is to identify the data security policies assigned to the custom role, then determine which policies you can deactivate and replace with access group rules.

Sign in to the application as a user with the IT Security Manager job role and select Navigator > Tools > Sales and Service Access Management.
Click the Manage Data Policies tab on the Sales and Service Access Management page.
On the Manage Data Policies page, select the custom role you want to migrate in the Role field.
For this example, let’s say the role is called Sales Representative Custom.
Select an object in the Object field. For example, select the Opportunity object to view the opportunity data security policies assigned to the role.
Click Find Policies.
The Active Policies table lists all the active data security policies for the opportunity object that are assigned to the Sales Representative Custom job role.
Click the Edit icon.
The Active Policies edit page for the selected role and object is displayed.
Review the policies listed and identify active data security policies that are unlocked and can be edited.
Some policies might be locked and can't be deactivated. For example, you can't deactivate policies that are inherited from predefined duty roles because predefined roles can't be edited. The permissions for these policies are grayed out.
Identify data security policies that are eligible for deactivation.

Don't edit any policy where the Condition name of the policy includes a reference to 'access group'. These policies, shown in the screenshot, are required for users to get access to object data through access groups and must remain associated with the custom role.
Check if all of the active, unlocked policies that are eligible for deactivation are required:
1. Make a note of each of the required policies and, for each policy, note the current permission levels selected.
  You'll need to activate corresponding access group rules that provide the same access levels as these policies.
2. Make a note of each policy that isn't required. You can deactivate these policies without having to activate a corresponding access group rule.
  
  You can deactivate any policies that grant access based on sales UI privileges. These policies are redundant. The Condition name of these privileges contains a reference to 'sales UI' as shown in the screenshot.
Repeat steps 3-8 for each object associated with the Sales Representative Custom role that you want to migrate to using access group rule data access. You can migrate a custom role to use access group rules for all objects, or just for specific objects.

Results:

At the end of the process, for your custom role and object, you should have identified and noted:

All the data security policies to be deactivated
All the policies marked for deactivation for which you have to assign a corresponding access group rule
The access levels you need to set for each rule you assign

Identify the Access Group Rules that Correspond to Data Security Policies

To replace data security policies with access group rules as a way of providing data access for a custom job role, identify the rule or rules that provide the same data access as each policy you're going to deactivate for the role. This chapter includes a table for each object that supports access groups. Each table lists the access group rules that correspond to each of the data security policies defined for the object.

Review the relevant table for the object you want to migrate and make a note of the object sharing rule that provides the same access as each policy you intend to deactivate.

Repeat step 1 for each object that you’re switching to use access group rules data access.

For example, to see how each data security policy defined for the Opportunity object maps to access group rules defined for that object, review the Opportunity Object Mapping table. Then repeat the process for Leads, Accounts, Contacts, and so on as required.

A data security policy can map to more than one access group rule. When you deactivate a policy, make sure you enable all the rules the policy maps to for the relevant access group. For example, the Opportunity Object Mapping table includes these rows:

Data Security Policy Business Object	Data Security Policy Predefined Instance Set	Data Security Policy Condition Name	Access Group Object	Predefined Rule Name	Predefined Rule Number	Predefined Condition Name	Predefined Condition Code
Opportunity	MOOOPTYZBS99904	Access the opportunity for table MOO_OPTY where they are member or in management chain of opportunity account team, account territory team or upward territory hierarchy	Opportunity	Account Territory Team	AccountPR9	Accounts where the access group member is a member of the territory associated with the account	ACCOUNTTERRITORY
Opportunity	MOOOPTYZBS99904	Access the opportunity for table MOO_OPTY where they are member or in management chain of opportunity account team, account territory team or upward territory hierarchy	Opportunity	Account Territory Team Hierarchy	AccountPR10	Accounts where the access group member is a member of the territory that is an ancestor of the territory associated with the account	ACCOUNTTERRITORYHIER

In this case, one data security policy (shown in column 3) provides data access based on territory team and territory-team hierarchy membership. But two access group rules, Account Territory Team and Account Territory Team Hierarchy (shown in column 5), must be assigned to provide the same access.

Add Rules to the Access Group Generated for the Custom Role

Once you've identified the access group rule or rules that correspond to each policy you intend to deactivate for a custom job role, you then assign the rules to the system access group generated for the custom role when the role was created. This way, you don't lose your existing access paths to object data.

When you create a custom job role, a system access group is generated for the role but it isn't assigned any access group rules. You can add the rules you identified in the previous step to your custom access group manually but it's generally easier to copy the object sharing rules from another access group that provides similar access, then edit the rules as required.

For example, when you created the Sales Representative Custom job role, a system group, Sales Representative Custom Group, was generated. You can copy the object sharing rules from the group generated for the predefined Sales Representative job role (Sales Representative Group), then edit the rules as required for the Sales Representative Custom Group. Here are the steps to use.

Navigate to the Sales and Service Access Management work area.
On the Access Groups page, select System Groups-Role from the List menu.
Select the access group whose rules you want to copy. For this example, select Sales Representative Group.
On the Edit Access Group: Overview page, select the Copy Rules option from the Actions menu. The Copy Object Sharing Rules dialog is displayed.
From the Copy to Group drop-down list, select the group you want to copy the rules to. In this example, select the Sales Representative Custom Group.
Click Save. The rules are copied to your selected group.
Click Save and Close on the Edit Access Group: Overview subtab.
Once the rules are copied, on the Access Groups page, select the access group you've just copied the rules to, in this case, the Sales Representative Custom Group.
On the Edit Access Group: Overview page, click the Object Rules subtab.
Review the new rules assigned to the group against the list of rules you noted in the previous step (Identify the Access Group Rules that Correspond to Data Security Policies).
Delete any rules that aren’t required by your access group by clicking the Delete icon for the rule.
Add any additional rules needed by clicking Add Rule, then selecting the rules to add.
For rules that are required:
1. Verify that the access levels defined for the rule are correct.
  
  The access levels for a rule should be the same as those defined for the corresponding data security policy. Change the access levels as needed.
2. Click the Enable check box for each rule you want to enable for the group.
3. Activate any rule that’s inactive by clicking the rule name link.
  
  On the Edit Object Sharing Rule page, click the Active check box to activate the rule, then click Save and Close.
On the Object Sharing Rules page, click Save and Close to save your changes.
Publish the new rules you copied and enabled for your custom access group by navigating to the Access Groups page, selecting the Object Rules tab, then selecting Publish Rules from the Actions menu.

Deactivate Data Security Policies

Once you've added the required access group rules to your custom access group, in this case, the Sales Representative Custom group, deactivate the policies you identified as candidates for deactivation in the step Identify the Data Security Policies to Deactivate.

You can deactivate a policy by removing all the permissions assigned to the policy. Alternatively, you can enter an end-date for the policy and specify a date in the past using these steps.

Navigate to the Sales and Service Access Management work area.
Click the Manage Data Policies tab.
Search for the custom job role, for example, Sales Representative Custom, in the Role field.
Select an object, for example Opportunity, in the Object field, then click Find Policies.
Click the Edit icon for the Active Policies table.

The Active Policies edit page for the selected role and object is displayed.
In the Active Policies table, for each policy you want to deactivate for the object, select a date that has passed in the policy's End Date field. For example, select yesterday's date.
Repeat steps 3-5 for all the other objects assigned to the role that you want migrate to using access group rules data access.
Click Save and Close.

Verify User Access to Data

Verify that the migration process didn't impact users access to object data.

Test users' access to each type of object data that you migrated to access group rules. Make sure that users assigned your custom role have the same access to data after the migration as they did before the migration.