Compliant Data Sharing
Compliant Data Sharing is the Salesforce sharing model designed for regulated industries (financial services, healthcare, government) that need explicit, audited record sharing with attestation, expiration, and supervisory controls.
Definition
Compliant Data Sharing is the Salesforce sharing model designed for regulated industries (financial services, healthcare, government) that need explicit, audited record sharing with attestation, expiration, and supervisory controls. Unlike standard sharing (which grants visibility through sharing rules, role hierarchy, manual share, or team membership and persists silently), Compliant Data Sharing requires a Participant record explicitly granting access, optionally with an expiration date, optionally with an attestation clause the recipient acknowledges, and always with a full audit trail of who granted what to whom when.
The model exists because regulated workflows need to prove who could see what data and when. Financial Services Cloud and Industries Cloud editions ship Compliant Data Sharing for objects like Financial Account, Account-Account Relationship, and custom industry objects. The pattern is heavier than standard sharing but produces the compliance evidence regulators expect during examinations. Most non-regulated orgs do not need it; the orgs that do need it cannot operate without it.
Why Compliant Data Sharing trades simplicity for audit-grade evidence
Where Compliant Data Sharing fits in the Salesforce sharing stack
Standard Salesforce sharing has multiple layers: org-wide defaults, role hierarchy, sharing rules, manual sharing, team membership, implicit sharing from related records. Compliant Data Sharing adds a parallel layer for specific objects where the standard layers do not produce sufficient audit evidence. When enabled on an object, sharing on that object goes through Participant records rather than (or in addition to) the standard mechanisms. The Participant record holds who granted, who received, what access level, when granted, when expires, attestation acknowledgement, and any business justification.
Where Compliant Data Sharing is available
Compliant Data Sharing ships with Financial Services Cloud and is being expanded to additional Industries Cloud products per release. As of 2026 it covers Financial Account, Account-Account Relationship, custom Wealth Management objects, and several Insurance industry objects. Custom objects can be enabled for Compliant Data Sharing through Setup if the org has the appropriate license. Standard objects in non-Industries clouds (Account, Contact, Opportunity in stock Sales Cloud) do not support Compliant Data Sharing; standard sharing applies.
The Participant record and the explicit-grant model
Every share through Compliant Data Sharing creates a Participant record on the shared parent object. The Participant captures: User (who received access), Access Level (Read, Read/Write, Owner), Role on Account (typical roles like Primary Banker, Trust Officer, Compliance Reviewer), Start Date and End Date (the temporal window of the share), and optional Reason (business justification). The record is queryable and reportable; auditors can pull a report of every active share, every expired share, and every share that occurred in the last quarter.
Attestation and the acknowledged-access pattern
For high-sensitivity shares, Compliant Data Sharing supports attestation: the recipient must explicitly acknowledge a clause ("I understand I am accessing client confidential financial data and will use it only for authorized purposes") before the share takes effect. The attestation is recorded on the Participant. Regulators specifically look for attestation evidence on sensitive data shares; the pattern is hard to retrofit but trivial to set up if planned at the Compliant Data Sharing rollout.
Expiration and the temporary-access workflow
Standard sharing persists until explicitly revoked. Compliant Data Sharing supports time-bound shares through Start Date and End Date on the Participant record. A loan officer assigned to a temporary case can have access from Monday to Friday and lose it automatically Friday at midnight. The platform handles the expiration automatically; no manual revoke needed. This matches regulated industry patterns where temporary access is common (vacation coverage, case escalation, audit review windows) and standing access for everyone is a compliance risk.
Audit, reporting, and the regulator question
The Participant object is fully reportable. Common compliance reports: every active share on Client X's accounts, every share added or removed in the last month, every share that included attestation. Regulators commonly ask "who could see Client X's data in March 2026?" Compliant Data Sharing answers the question through a single report query. Standard sharing requires reconstructing the answer from sharing rules, role hierarchy, manual shares, and team memberships across history; the reconstruction is often impossible at the precision regulators expect.
Operational cost and when it is the right choice
Compliant Data Sharing adds operational overhead: every share is a record-create action rather than a permission set or role assignment. The cost is real; bankers spend time creating Participant records, supervisors spend time approving them. The cost is worth it for regulated work where the audit evidence is required by law. For non-regulated work, standard sharing is faster and easier; using Compliant Data Sharing where it is not required adds friction without compliance benefit. The decision is binary: required by regulation (use it) or not required (do not).
How to deploy Compliant Data Sharing in a regulated org
Deployment is significant. The pattern: identify objects requiring compliant sharing, enable the feature, design the Role-on-Account taxonomy, train users on the Participant workflow, build the compliance reports. Each step is mandatory; skipping any reduces the audit-evidence value the feature was deployed for.
- Identify objects requiring Compliant Data Sharing
Coordinate with compliance. The list typically includes Financial Account, custom industry objects holding regulated data, Account-Account Relationship in wealth management orgs.
- Enable Compliant Data Sharing per object
Setup, Financial Services or Industries area, Compliant Data Sharing. Enable for each object identified. Some objects support both standard sharing and Compliant Data Sharing simultaneously.
- Design the Role on Account taxonomy
List the role labels Participants will use (Primary Banker, Wealth Advisor, Trust Officer, Compliance Reviewer). The taxonomy drives the reporting categories regulators ask about.
- Configure attestation clauses for high-sensitivity objects
For shares of client confidential data, configure the attestation text. Coordinate with legal for wording.
- Train users on the Participant workflow
Bankers, advisors, supervisors. The workflow is heavier than standard sharing; training is non-optional.
- Build the compliance reports
Active Participants per Account, shares added per period, attestation completion rate, expired shares per period. These reports are the audit-evidence surface.
- Schedule the quarterly compliance review
Pull the reports, review with compliance, document any anomalies. The cadence is the operational discipline that produces continuous evidence.
Which objects use Compliant Data Sharing. Per-object decision aligned to regulatory scope.
The role labels used on Participant records. Drives reporting categories.
Per-object attestation text recipients acknowledge before access takes effect.
Default expiration on new Participant records. Time-bound by default is the safer pattern.
Whether standard sharing layers still apply on the same object. Some configurations allow both; others require Compliant Data Sharing exclusively.
- Compliant Data Sharing requires Financial Services Cloud or Industries Cloud licensing. Stock Sales Cloud and Service Cloud do not have it.
- The model is heavier than standard sharing. Every share is a record-create action; users and supervisors spend more time on sharing administration.
- Attestation must be configured before the high-sensitivity workflow goes live. Retrofitting attestation after the fact is operationally heavy.
- Default expiration is non-trivial to retrofit. Set the time-bound default at rollout; switching from indefinite to time-bound later requires updating historical Participant records.
- Standard sharing can coexist on the same object depending on configuration. The combined behavior can surprise users; document explicitly.
Trust & references
Straight from the source - Salesforce's reference material on Compliant Data Sharing.
- Compliant Data SharingSalesforce Help
- Financial Services Cloud OverviewSalesforce Help
- Set Up Compliant Data SharingSalesforce Help
Hands-on resources to go deeper on Compliant Data Sharing.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. In which area of Salesforce would you typically find Compliant Data Sharing?
Q2. What is the primary benefit of Compliant Data Sharing for Salesforce administrators?
Q3. Can a Salesforce admin configure Compliant Data Sharing without writing code?
Discussion
Loading discussion…