Enable Territory-Based Access to Custom Objects

You can provide resources with access to custom object data, where access is based on the resource's membership in a territory, also known as territory-based access group security. With this type of security, the territory that the user assigns to a record controls who can see, edit, and delete the record.

Overview of Setup Steps

To enable territory-based access group security for a custom object, complete these steps:

1. Set up your territories and territory hierarchy.

   See Steps to Implement Territories.

2. Configure the custom object in Application Composer.

3. Configure the access group object sharing rules for the custom object in the Sales and Service Access Management work area.

Let's look at the setup steps in more detail.

Application Composer Setup

In Application Composer, complete these steps inside a sandbox.

1. For your custom object, create a dynamic choice list field using the below configuration.

   Sales Territory Dynamic Choice List Setup

   Dynamic Choice List Attribute	Value
   Display Label	Sales Territory
   Related Object	Sales Territory
   List Selection Display Value	Name
   Data Filter > Advanced Filter	Add the following filter condition so that users can associate only active territories with custom object records: (EffectiveEndDate > :todayDate) AND (StatusCode = 'FINALIZED')
   Additional List Display Values	Owner Type Territory Function Status
   Additional List Search Fields	Owner Type Territory Function Status

2. Add this Sales Territory field to the details page layout for the custom object, so that at runtime, your users can add a territory to custom object records.

3. Configure security so that the territory team member on the custom object record as well as his management hierarchy have access to the record.

   To do this, set security on the custom object:

   1. Navigate to the Security node for the custom object.

   2. On the Define Policies page, select the Enable Access Group Security check box.

   3. Select the Configure Territory for Access Group Security check box and then select the dynamic choice list field that you just created, Sales Territory.

4. Configure functional security for the required roles.

   This step isn't related to access group security (data security), but it's a required step so that the right roles can access the custom object's user interface pages at the appropriate level (functional security).

   1. Navigate to the Security node for the custom object.

   2. On the Define Policies page, select each role that needs access and, for each column (Read, Update, Delete), select the access level for reading, updating, and deleting records: Functional Read, Functional Delete, or Functional Update.

5. Publish your sandbox.

Object Sharing Rules Configuration

In the Sales and Service Access Management work area, enable your custom object for access group object sharing rules.

1. Navigate to Access Groups in the Sales and Service Access Management work area.

2. On the Object Sharing Rules page, select the Synchronize Custom Objects and Fields item from the Actions menu.

   After you sync, your custom object displays in the Object list.

3. Select your custom object from the Object list to configure object sharing rules.

   In the Rules region, these predefined rules display:

   • (Custom Object) Territory Owner

   • (Custom Object) Territory Owner Hierarchy

   • (Custom Object) Territory Team

   • (Custom Object) Territory Team Hierarchy

   In this context, hierarchy refers to territories and not resources.

4. Click each rule to assign a custom access group and access level.

   (Access groups are automatically created and populated based on the roles created using the Security Console.)

5. On the Access Groups Monitor page, optionally schedule and run the Perform Object Sharing Rule Assignment process to assign access group object sharing rules to your custom object.

   By default, the process runs automatically at scheduled intervals to make sure you have the required access to all object data for your selected access groups. But you can submit the process manually if, for example, you want immediate access to new records and objects.

For more information, see the Access Groups chapter in the Oracle Fusion Cloud Customer Experience Securing Sales and Fusion Service guide.

Object Sharing Rules Example

When a territory is assigned to a record, the object sharing rules dictate what the territory owner and team members (as well as owners and team members in the territory hierarchy) can see and do with the record.

Let's say you have two sales roles: one for sales managers and one for sales representatives. This means that the automatically created access groups are Sales Manager Custom Group and Sales Representative Custom Group. You might configure object sharing rules as described in the below table.

Based on the below rules:

• If the resource owns the assigned territory (Pacific Northwest) and is in the Sales Manager Custom Group, then they can see and edit the record.

• If the resource owns the assigned territory and is in the Sales Representative Custom Group, then they can only see the record.

• If the resource owns the territory (United States) that's part of the territory hierarchy and is in the Sales Manager Custom Group, then they can see, edit, and delete the record.

• If a resource is a sales manager or sales representative but isn't part of either the assigned territory (Pacific Northwest) or territory hierarchy (United States), then the resource can't access the record at all.

Object Sharing Rules Example

Rule Name	Group Name and Access Level
(Custom Object) Territory Owner	Sales Manager Custom Group: Read and Update Sales Representative Custom Group: Read
(Custom Object) Territory Owner Hierarchy	Sales Manager Custom Group: Read, Update, and Delete
(Custom Object) Territory Team	Sales Representative Custom Group: Read
(Custom Object) Territory Team Hierarchy	Sales Manager Custom Group: Read, Update, and Delete Sales Representative Custom Group: Read