Considerations and Limitations for Compliant Data Sharing

General

A maximum of 10 participant roles can be active for each parent object.

A maximum of 100 record participants can be added to each parent record. For example, only 100 account participants can be added to an account record.

A maximum of 100 participant groups can be added to each parent record, regardless of the number of participants in each group. For example, create two participant groups with 150 participants in each group. Then share one account record to the two participant groups. This sharing counts as two account participants.

A maximum of 50 million participant records can be added for each participant object.

A user can’t be deactivated if they’re a record participant or if they're a member of a participant group. Delete a user’s participant records and participant group member records before deactivating.

A maximum of 10 participant roles can be active for each object enabled for Compliant Data Sharing.

You can create up to 5 levels of participant groups.

If a user is a member of more than one participant group on the same record, the user is granted the most open level of access to the record.

You can send mass email to a maximum of 5,000 external email addresses per day per licensed Salesforce org based on Greenwich Mean Time (GMT).

Custom report types aren’t supported with custom objects. So you're not able to create custom reports for Custom Object Participants.

If you change the participant role access for several participant roles, we recommend allowing the operation to complete for each participant role before moving to the next one.

The default Participant Record Limit is 50 million, and 20 million for the Scratch Org Feature.

When a user is added as a participant to a record, then updated to record owner, and then removed as owner, the user no longer has access to the record. To grant the user access to the record, deactivate and then reactivate the user's participant record.

Share Tables

The Compliant Data Sharing feature creates and updates object sharing table entries based on a user’s assigned participant role and the access level for that role. The sharing table entries created by this feature have a new sharing reason called Compliant Data Sharing.

Enforcement of account and opportunity data access for other features like reports and list views are unaffected by Compliant Data Sharing. All other data sharing features continue to work as usual.

If there are multiple share table entries for the same user, the one with the least restrictive access level is enforced.

Share table entries are created only if the participant role access level is less restrictive than the org-wide sharing default for the object. If the org-wide default changes to a less restrictive level than the participant role’s level, the participant’s corresponding share table entries are automatically deleted.

Important Compliant Data Sharing adds to other sharing settings, including role hierarchy access . It grants access to participants but can't remove or deny access that they already have through another sharing feature . For standard objects, such as opportunities, the Grant Access Using Hierarchies setting is always on and can't be turned off, so users above record owners in the role hierarchy retain access even after you turn on Compliant Data Sharing . To restrict records so that only explicitly assigned participants can access them, use an object that supports more granular, participant-based access, such as financial deals.

Security

• A user who has a participant role assigned for a record or who belongs to a participant group can't be deactivated. Delete their participant records and remove them from all participant groups before deactivating them.
• You can't delete or deactivate a participant role that has existing account participant or opportunity participant records. Delete the participant records first.
• To deactivate a participant role, deselect Active.
• When the default access level is changed for a role, it triggers updates to share table entries for all records that are assigned to that role. The update process can take some time to complete. When the update completes, a notification email is sent and an entry is added to the Setup Audit Trail describing the changes.
• Grant access using hierarchies isn't supported for participant groups.