Thought Process behind this implementation
Last month I finished two super-badges related to Einstein Analytics to learn something about it due to some project related work. While completing the modules the area which I felt was the most needful that is the security. As most of you know that we will be dealing with the Customer Data which should be very secure, not only from the outsiders also from their employees as well, so I thought of to write something.
8. When setting
up sharing inheritance, you specify from which objects to migrate the sharing rules. In Our Example that will be Opportunity sharing rule. It has some limitations in its Own.
10. Please consider the below table and try to understand the how data accessibility works after implement of security predicates :-
Refer the role hierarchy declared under the section of "Use Case".
How Architecture works behind
Use Case
In our current world one of the most important parameter is the sales data , let's talk about Opportunity Data which is the most important thing when it's about sales data. Let say ABC organization are maintaining the below hierarchy : -
Now we are going to talk about that after implementing Einstein Analytics security predicate on sales data how the visibility works for each and every employee.
How Security Works :
- When we are enabling the Einstein Analytics in Salesforce org, Analytics gains access to Salesforce data based on permissions of two internal Analytics users: Integration User Profile and Security User Profile.
- Analytics uses the permissions of the Integration User to extract data from Salesforce objects and fields when a data-flow job runs. Because the Integration User has View All Data access.
- When you query a Dataset that has row-level security based on the User object, Analytics uses the permissions of the Security User to access the User object and its fields. The Security User must have at least read permission on each User object field included in a predicate. A predicate is a filter condition that defines row-level security for a Dataset. By default, the Security User has read permission on all standard fields of the User object.
- So to use Salesforce data in Analytics we need both of the Profiles.
- Analytics App are like salesforce folder which can be Private and shared , by doing that it can control sharing of everything what are there in the App.
- App can be shared with users, groups, or roles.
- If an Analytics user has access to a dataset, the user has access to all records in the dataset by default. However, you can implement row-level security on a dataset to restrict access to records or turn on sharing inheritance, or do both.
Turn On the Sharing Settings:
- From Setup, in the Quick Find box, enter Analytics, and then click Settings.
- Select Inherit sharing from Salesforce, and click Save.
9. To overcome the limitations we have to introduce Security Predicate. which might be : -
- Security Predicates for Datasets .
- Row-Level Security based on Record Ownership
- Row-Level Security Based on Territory Management
- Row-Level Security based on Opportunity Teams
- Row-Level Security Based on Territory Management
Refer the role hierarchy declared under the section of "Use Case".
- Observation 1 : Once the data set gets created and nothing will be imposed in terms of security predicate. Then CEO, Sales Rep1 and Sales Rep2 will see all the records as long as they have the access to those fields.
- Observation 1 : Suppose once sharing rule already created in salesforce and once you are going to enable "inherit sharing" it will start following the security access mentioned in the sharing rule. Based on the Sales Rep1 and Sales Rep2 will see their records.
- Observation 1 : if you want to narrow down bit more then you might enable security predicate based on your need. Everything is described very clearly in salesforce documents So I am not getting into details , I will put that in reference link, please find some examples below : -
- 'UserId' == "$User.Id"
- 'Territory' == "$User.Territory__c" || 'Executive_ProfileId' == "$User.ProfileId"
No comments:
Post a Comment