Enterprise Territory Management Security Predicate_Row level Security in CRM Analytics Aka Tableau CRM aka EInstein Analytics

Analytical Security Overview:-

                                                         Analytical Cloud has three layers of security which is as follows

1. Analytics platform Layer
2. Analytical Application Layer
3. Dataset record Layer/Data Visibity

Dataset Record Layer:-

                                           Dataset Record layer is nothing but controlling what records user's need to see on Dashboard. which can be defined by  below two ways.

• Security Predicate
• Sharing Inheritance

Security Predicate:-

                                               When a new dataset is created, the security predicate is empty, which means everyone has access to the dataset, has access to all the data rows. Security predicate is a manually assigned filter condition that defines row level security for dataset. When a user submits a query against a dataset that has a predicate, Analytics checks the predicate to determine which records the user has access to. If the user doesn’t have access to a record, Analytics does not return that record. 

                                  The predicates can be formulated to control the data visibility based on the following scenarios:

1. Role Hierarchy
2. Manager Hierarchy 
3. Logged in User’s Country
4. Opportunity Team and Accounts Team
5. User Territory 

This blog will discuss about a implementaion of Dataset record /Data Visibity layer by using User Territory or Enterprise Territory Mnagament based Security Predicate. 

Before Jumping into User Territory or Enterprise Territory Management based Security Predicate implementation let us recall basics about Salesforce Enterprise Territory Management.

What is Salesforce Territory Management?

Salesforce Territory Management is a tool that helps organizations like yours manage accounts and opportunities by territory. It lets you organize your accounts by any field and create hierarchies of accounts. For example, you can create a hierarchy with c-suite VPs at the top, regional managers in the middle, and sales reps on the bottom. Or you could create a hierarchy based on global regions, countries, states, cities, and even neighborhoods within major cities.

In essence, Salesforce Territory Management lets you structure your Salesforce users, accounts, and data the same way you structure your sales territories in the real world. By structuring Salesforce data in this manner, your reporting and analysis becomes more relevant and useful.

So Whenever the Org is enabled or follwing Terriory Mannagement system for account distribution then obviously we would need to go with Enterprise Terriory Mannagement based security predicate to strict the users to see unrelated records .

Data Sources for Implementation :

                                                                For any of the Data project implementation identifying the data resouces for the requirement is crucial steps . so for our requirment  of implementing Secuiry predicate involves with the below Salesforce objects where necessary details resides.
     
                                                

Data Sources

Account

AccountShare

Territory

UserTerritory

Group

User

Below are the object definition for our datasources of this implementation:

Account:

                  Represents an individual account, which is an organization or person involved with your business (such as customers, competitors, and partners).

 AccountShare:

                             Represents a sharing entry on an Account.

Territory:

                  Represents a flexible collection of accounts and users where the users have at least read access to the accounts, regardless of who owns the accounts. Only available if territory management has been enabled for your organization.

UserTerritory:

                            Represents a User who has been assigned to a Territory.

            Special Access Rules:

                                                   Only available if territory management has been enabled for your organization.

Group:

              A set of User records.

Groups are sets of users. They can contain individual users, other groups, the users in a particular role or territory, or the users in a particular role or territory plus all the users below that role or territory in the hierarchy.

User:

           Represents a user in your organization

Reference Link : 

Salesforce Object Reference

Scenario: 

All users only to see data related to their assigned territory  and owners can only see their own records. 

Predicate Expression Syntax for Datasets:

  The predicate expression must have the following syntax: 

                    <dataset column> <operator> <value>

Dataset Columns in a Predicate Expression :   You include at least one dataset column as part of the predicate expression. 

Values in a Predicate Expression :   The value in the predicate expression can be a string literal or number literal. It can also be a field value from the User object in Salesforce.

Consideration

     By considering the Values in a Predicate Expression   criteria , Territory Id is not an associated field in the user object. So we cannot be able to use Flattened Territory Id field in our Security predicate formula. By that we have to bring all the user id belongs to respective territory account in one column as comma seperated or multivalue . So that we can be able to match that record with "user id" in User object .

Data Model :

                                          Data modeling is an essential step in the process of creating any complex ELT or ETL or Data Wrangling process job.

The process of data modeling thus uncovers your data and its relationships, which provides a foundation for understanding your business processes and how to improve them. You simply can’t create Data transformation if you don’t know how your business is operating and its data sources,relationships.

For example, to create a Territory based dataset , you need to understand the data of your business currently has on for territory setup and how you’re using it.

Based on the consideration  we have plotted our data model. therefore now we can be able to create a Data Recipe faster and accurate .so its recommended to create a Data model for each and every ELT or ETL or Data wrangling project.

Data Recipe :

Discussion:

                     Since our expectations is to have all the user's id related to an account assigned to that terriroty at each row. 

Step 1 :-

  Augumenting User Name from User Object on to User territory  object to see user name with respect to the territory User's.

 Step 2 :-

 we are Flattening the territories since it is nested. and which flattened field will be helpful while perfoming unit testing.

 Step 3 :-

performing self join on Territory2 object to get the Parent terriotiry Name .

 Step 4 :-

Augumenting  User Id from User territory object on to Territory2 object in order to rolled up the user Id to each of the teritory as a multivalue field. 

 Step 5 :-

Account object doesnot have any field or forign key field  of Territory Id or anything related to territory . but Account share having fields related to Group Id. Hence we would need to have  Territoy Details at the Group level records granular level.  so augumenting Territory Id from  Join_TerritoryUsers onto _Territory Node  on to Group object.

 Step 6 :-

 Now we have required data at the group object Granular level. basically we would need to have list of users at the account level whoever having access to that account assigned territory.  in that case Account share object having a  field of UserOrGroup Id   field where User or Group Id is stamped whoever having access to that account. so need to  Augumenting  Territoy Details  from Join_Territory onto _Group Node  on to Accountshare object.

 Step 7 :-

Phew !!! finally we are having everything at the Account level. but Account share object is a one to many relationship with Account Object. Hence we would need to rolled up to the Account level. so Augumenting  Territoy Details  from Join_Group onto _AccountShare Node  on to Account object .

 Step 8 :-

if you are creating Account Territory Recipe as Separate Recipe then you can register as Dataset. after that you would need to load this dataset to every Recipe and data stream to have a predicate column at the dataset level.

Key Take away : 

If you are creating "Account territoty Security" Recipe as sepearet one then this Recipe should be Run after the Data Sync Run.because predicate field should be avilable to every dataset so that we will have update predicate fields whenever its runs on prior to any recipe.

Security Predciate Apply:- 

Finally we are having predicate field on the Account level. now we can go ahead and apply the predciate expression on each dataset.

1. Edit all the dataset created and create security predicate as follow

'Territory.AccountShare.Group.territory.TerritoryUsers.UserId' == "$User.Id" || 'AccountShare.UserOrGroupId' == "$User.Id"

The first part (in green) is to allow users to see only data where user Id in the dataset is the same as login user id from the user object.

The second part (in yellow ) allows records(Account) Owners only to see data of their own, that's why we use or logic (||).

Note:- second part of Security predicate expression

For the datasets other than Accounts  'OwnerId' == "$User.Id" expression would be the correct one.

Using the same method, you can have  "n" number of  an condions too based on the business requirment.

Key Take away : 

Scenario 1 :-

If the Deafault access level for the below object is as follows, then  we would need to keep the 'Territory.AccountShare.Group.territory.TerritoryUsers.UserId' == "$User.Id" expression as in 1st position . so that users can see data related to the respective terriory Account.

Opportunity Access : View all opportunities associated with accounts in the territory, regardless of who owns the opportunities

Case Access : View all cases associated with accounts in the territory, regardless of who owns the cases

Event Access : View all Events associated with accounts in the territory, regardless of who owns the cases

Scenario 2 :-

If the Deafault access level for the below object is as follows, then  we would need to keep the  'OwnerId' == "$User.Id"  expression as in 1st position which covers on the lower hierarchy level in the terrioty can see only their own data.   'Territory.AccountShare.Group.territory.TerritoryUsers.UserId' == "$User.Id" expression as in 2nd position follwed by OR condition . If the users who are all dont have the own data then it willl allows the users to see data of their territory hierarchy. ex : territory hierarchy managers can see their subordinates data.

Opportunity Access : View all opportunities of their owns.

Case Access : View all cases of  their owns. 

Event Access : View all Events of their owns.

Disclaimer: Org used in this demonstaration is Salesforce Trailhead Development Org

Reference Link : 

Predicate Expression Syntax

Analytics Security Implementation Guide