Security Predicate is great to set row-level security for Einstein Analytics user to access the dataset based on certain criteria, such as matching user custom field “Region” in Salesforce with data with a field call Region, so the user will only see data with the same region as per user detail. This will work whether data comes from Salesforce or from the external system.
However, if the data source is from Salesforce and we want to bring in row-level security based on Salesforce sharing, there is something called Sharing Inheritance. Sharing inheritance lets Einstein Analytics apply the same sharing setup for your datasets as Salesforce uses for your objects
However, there are a few limits to note when implementing Sharing Inheritance:
- Each dataset can inherit sharing settings from one object, regardless of how many source objects are used to create it
- All object records have fewer than 400 sharing descriptors each
- Supported objects for sharing inheritance are: Account, Case, Contact, Lead, Opportunity
A sharing descriptor is the ID of the user or group that has access to the record. Sharing descriptors, tracked by Salesforce in the Object Sharing Table, ensure that only the listed users and groups can access the correct records. IDs are added to the sharing table for many reasons including record ownership, sharing rules, and manual sharing.
When object records and users have fewer than your org’s maximum descriptors, go ahead and apply Sharing Inheritance. If records exceed the limit, depending on your org’s sharing strategy flexibility, choose to reduce the number of descriptors per record or contact Salesforce Support to evaluate whether higher limits are an option.
You can build your own security predicate to mimic Salesforce sharing in dataflow, from record owner, role hierarchy, teams, manual sharing, sharing rules, and etc. but it is way too complicated, check out this blog for almost complete.
To implement Sharing Inheritance, go to the Salesforce setup menu, and enable it from Settings under Analytics. Once enable, navigate to Sharing Inheritance Coverage Assessment to assess if sharing inheritance can be used for a particular object and any users will not be covered:
- Select the object
- Click “View Assessment” to check if the object can use sharing inheritance
- If yes, click “View User Coverage” to make sure if any users do not cover by sharing inheritance, this is for users with sharing descriptors more than max descriptors for the Org.
Sharing inheritance covers a user if they have “View All Data” permission, or their record access is granted by fewer than 3,000 (by default) sharing descriptors — note that this is NOT the number of records visible by a user on that object. The backup security predicate takes effect for users with more than this number of sharing descriptors. Without a security predicate, users not covered by sharing inheritance see no data in the dataset, because they have no dataset row-level access.
For an object to appear in the security-sharing source list, the primary key of the custom object must be a field in the dataset. A foreign key doesn’t satisfy this requirement. For example, if you have Opportunity.AccountId in your dataset but not Account.Id, you can’t inherit sharing from the Account object.
To configure sharing inheritance in dataflow, on the Register node, select the object under Sharing Source. In dataflow JSON, this will be stored as “rowLevelSharingSource” parameter.
By editing the dataset, you can check the sharing source for that dataset, this should be similar to sharing inheritance defined in the register node in the dataflow.