Analytical Security Overview:-
Analytical Cloud has three layers of security which is as follows
- Analytics platform Layer
- Analytical Application Layer
- 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:
- Role Hierarchy
- Manager Hierarchy
- Logged in User’s Country
- Opportunity Team and Accounts Team
- 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 |
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 :
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>
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
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.
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:-
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.
Key Take away :
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 :
Analytics Security Implementation Guide
