Sharing Inheritance Limits and Considerations

Sharing Inheritance Limits

• Sharing inheritance can be applied from a supported object if all object records have fewer than 400 sharing descriptors each. Supported objects for sharing inheritance are:
  • Account
  • Case
  • Contact
  • Lead
  • Opportunity

Note Objects must be local and extracted using the sfdcDigest transformation. Enable sharing inheritance for each object as described in Enable Sharing Inheritance. All users on an unsupported object list as UNSUPPORTED on the Sharing Inheritance Coverage Assessment Report, described here.

• Sharing inheritance covers a user if they have “View All Data” permission or their record access is granted by fewer than 3,000 sharing descriptors. The backup security predicate takes effect for users with more than this number of sharing descriptors without the “View All Data” permission. A sharing descriptor is record access granted through several methods, including:
  • Owning the record
  • Role hierarchy
  • Sharing Rules
  • Manual sharing
  • Apex managed sharing

Note You can’t easily count how many sharing descriptors are associated with a user or record without a developer’s help. Instead, fetch the list of records or users not covered by sharing inheritance with the Sharing Inheritance Coverage Assessment Report. Users with more than 3,000 sharing descriptors have the uncovered reason HIGH_VISIBILITY.

• Sharing inheritance only works for Salesforce users. It isn’t available for Experience Cloud Sites users and logins. To provide security in Experience Cloud Sites, you must use security predicates.
• Recipe datasets generated by append or upsert output nodes don't support sharing inheritance.

General Considerations

• It's best practice to have a defined security predicate for datasets using inherited sharing. Without a security predicate, users not covered by sharing inheritance see no data in the dataset because they have no dataset row-level access.
• Sharing isn’t automatically applied to datasets. You can apply sharing to each dataset manually.
• Sharing inheritance can affect the performance of queries, dataflows, and Data Prep recipes. If your requirements include the best-possible performance, use security predicates instead of sharing inheritance. If not, enjoy the convenience of sharing inheritance.
• Changes to the rowLevelSharingSource or rowLevelSecurityFilter security settings in a dataflow only affect datasets created after you save the change. Similarly, changes to a Data Prep recipe output node’s Sharing Source and Security Predicate fields only affect datasets created after you save the change. Update those settings for existing datasets on the edit dataset page.
• 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.
• Sharing inheritance uses your Salesforce org sharing settings. If you don’t want to apply incomplete Salesforce org sharing settings to CRM Analytics, don't use sharing inheritance.
• Sharing inheritance isn't available for Data Prep Classic recipes.

Information Leak Considerations

When using sharing inheritance, consider these points to avoid data leaks to users who shouldn’t have access.

• A dataset can inherit sharing settings from only one object, regardless of how many source objects are used to create the dataset. Because many objects comprise the dataset, each object can use a different security model.
• The computeRelative and delta dataflow transformations can merge information from records with different security.
• Calculated fields are treated as normal fields. Row-level security applied during the calculation in Salesforce is ignored.
• Security predicates referencing $User information require a new user session before a new value is recognized.

Important If your dataflow doesn't do a full extraction each time it runs, evaluate whether security drift is a risk for the datasets you bring into CRM Analytics. Consider whether to use periodic full sync. For more information, see Security Metadata Drift.