Pages

Sunday, February 21, 2021

Einstein Analytics: Sharing Inheritance

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.

sample of sharing inheritance can be used in Account for all users


sample of sharing inheritance that cannot be used in Account, because some records have too many associated sharing descriptors


sample of sharing inheritance can be used in Case, but some users are not covered because those users have more sharing descriptors than the org limit


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.

in this sample, I have Id (of Account) and Opportunity.Id fields


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.



 
Reference




6 comments:

  1. Thank You for the as always amazing blog John.
    John I am facing a tedeous issue in data flow.. I posted in community also but no solution yet. Will it be fine if I posted here to you can you please kindly suggest me any solution on it. It will be very helpful ��

    ReplyDelete
  2. Good article, thanks for posting.
    Wondering if sharing inheritance will be able to block a TCRM Admin user from seeing certain data COMPLETELY (even without adding security predicate)?

    Our business case is that we have some sensitive Opp data in SF which should not be exposed to TCRM Admins in any case (they are not the SF admins and don't have view-all data permission in SF either). What do you think is the best approach for it?

    Thank you so much

    ReplyDelete
    Replies
    1. assume the TCRM admin cant see the data in Salesforce, so if you use sharing inheritance, so they will not see in TCRM too, but of course the TCRM admin can create other dataflow or recipe without sharing inheritance, then it will be visible for them

      Delete
    2. I see, thanks Johan. You're right, Sharing Inheritance will not be applied automatically.. so bascially there is no way to actually block it, which is a kind of loophole in some cases.

      Delete
    3. You can have a very thorough governance process with penalty, but still it is not a prevention.

      Delete

Page-level ad