Sharing in vanilla Salesforce is record-centric. You share a record (an Account, an Opportunity, a Financial Account) with a user or a group, and they get access to that record. The access pattern is binary: you can see the record or you cannot.
Financial services need something more nuanced. A wealth advisor needs full access to a Primary Owner's accounts but only partial access to a Joint Owner's accounts. A compliance officer needs to see every Person Account marked PEP but not their full transaction history. A relationship manager needs to see a household's combined net worth without seeing the individual statements of each spouse.
Compliant Data Sharing (CDS) is the FSC managed package that bridges standard Salesforce sharing with the role-aware access patterns financial services require. Most implementations underconfigure it. The result is either over-shared data (privacy violations) or under-shared data (unhappy advisors who cannot do their jobs).
What CDS actually does
CDS sits on top of standard Salesforce sharing. The standard sharing engine still decides record-level visibility: a record is shared with a user or not. CDS adds a second layer that defines what the user sees on the shared record once they have access.
The CDS configuration consists of three components:
Participant Role. A label for a kind of relationship. Primary Advisor, Secondary Advisor, Compliance Officer, Operations Reviewer. Each Participant Role is the access-side identity that gets configured.
Data Use Purpose. A reason the data is being accessed. Wealth Advisory, Compliance Review, Operations Processing, Customer Service. Each Purpose carries the access scope tied to it.
Resource Access Rule. The rule that ties Participant Role plus Data Use Purpose to specific record access. A Primary Advisor accessing for Wealth Advisory Purpose gets full read access to client Financial Accounts; the same Primary Advisor accessing for Compliance Review Purpose gets a different access pattern.
The combination of Role, Purpose, and Rule produces fine-grained access. The trade-off is configuration complexity.
Where CDS earns its complexity
Three access patterns CDS handles cleanly that standard sharing handles poorly:
Role-based field masking. A Beneficiary on a Financial Account should see the account exists and see the beneficiary designation, but should not see balance or transactions. With standard sharing, exposing the record means exposing all fields. With CDS, the same record exposes different fields to Beneficiary versus Primary Owner.
Purpose-based access scoping. The same advisor accessing a Person Account for a routine wealth review should see full client data. The same advisor accessing for compliance investigation should see compliance-flagged data only. Purpose-based scoping lets the same person have different views depending on context.
Time-bounded access. A temporary access grant (a covering advisor while the primary is on holiday, an external auditor with a defined review window) needs a defined end date. CDS supports time-bounded Resource Access Rules; standard sharing typically does not.
Each of these has a workaround in standard sharing (multiple record types, multiple page layouts, manual access management) but the workarounds break down at scale. CDS handles all three through one configuration surface.
The setup pattern
CDS configuration goes in roughly this order:
Step 1: Define Participant Roles. Start with the roles that have distinct access patterns. Most FSC orgs end up with 5 to 10 roles. Common ones: Primary Advisor, Coverage Advisor, Compliance Officer, Operations Reviewer, Customer Service Representative, External Auditor.
Step 2: Define Data Use Purposes. Map each kind of access context to a Purpose. Most orgs end up with 3 to 5 Purposes: Routine Advisory, Compliance Review, Operations Processing, Customer Service, Audit.
Step 3: Define Resource Access Rules. Map combinations of Role plus Purpose to access scopes. The rules are where the rubber meets the road. Each rule defines what objects, what fields, and what operations the combination allows.
Step 4: Wire Up Account-Account Relationships. Many access scenarios depend on relationships. An advisor's access to a client's Household propagates to all members. The Account-Account Relationship records define the propagation paths; the Resource Access Rules reference them.
Step 5: Test against real personas. Standard QA scripts walk a typical advisor through their morning workflow and verify each access point. Failures here are usually configuration gaps, not platform bugs.
The setup takes weeks, not days. The payoff is access that matches the bank's actual access policy.
What can go wrong
Two failure modes appear regularly on FSC implementations:
Over-permission. The rules grant broader access than the policy intends. Advisors see information they should not see. Often this surfaces during an internal audit or a regulatory review, with consequences. The fix is usually to tighten the Resource Access Rules and run a remediation report on access that occurred before the tightening.
Under-permission. The rules grant less access than the workflow needs. Advisors cannot do their jobs. The fix is to expand the rules carefully, with each expansion reviewed against the policy.
The bias should be toward under-permission during initial rollout. It is easier to expand access in response to a workflow gap than to investigate a privacy violation after the fact.
Performance implications
CDS adds an evaluation step to every record access. The standard sharing decision (does this user see this record) is now a 2-stage decision: standard sharing first, then CDS overlay second. The performance cost shows up at scale.
Three mitigation patterns:
Selective rule application. Apply CDS only to the object types that need it (Financial Account, Person Account, Household, Policy). Vanilla Salesforce objects that do not need CDS-level access control should not be in the CDS scope.
Indexed rule evaluation. The CDS evaluation engine uses indexes on the key fields (Participant Role, Data Use Purpose, target object). Ensuring these indexes are healthy keeps the evaluation fast.
Rule consolidation. A small number of broad rules performs better than a large number of narrow rules. As the rule library grows, periodic consolidation keeps the engine performant.
The performance cost is real but manageable. Production FSC orgs with active CDS configurations typically see single-digit-millisecond access checks, well within the user-experience budget.
Audit and review
CDS provides audit logs that show what access actually happened. Each access event records the user, the record, the Participant Role used, the Data Use Purpose, and the timestamp.
The compliance team uses the audit logs in three ways:
Periodic access review. A quarterly review of who has been accessing what. Anomalies (an advisor accessing clients outside their book, a compliance officer accessing volumes far higher than peers) get flagged for investigation.
Incident response. When a privacy concern arises, the audit log is the first place to look. The log shows whether the suspect access actually occurred and what was accessed.
Regulatory reporting. Some jurisdictions require regular reporting on access controls and access patterns. The audit log is the data source.
The audit log retention policy needs explicit design. Most banks keep CDS audit logs for 7 years to align with broader record-retention obligations. The storage cost is non-trivial but unavoidable.
When CDS is not enough
A small set of scenarios outstrip what CDS handles cleanly:
Cross-org access. Sharing data across separate Salesforce orgs (for example, a wealth org and a separate banking org) is not what CDS is designed for. Custom federation patterns or Salesforce-to-Salesforce sharing handle these cases.
Real-time external integration access. When an external system needs to query Salesforce data, CDS evaluation may or may not apply, depending on the integration path. Named Credentials with restricted permission sets give the cleanest pattern for external access.
Programmatic access from Apex. Apex runs in system mode by default, which bypasses sharing entirely. CDS does not apply to system-mode Apex. The fix is to write the Apex with explicit sharing (the with sharing keyword), and even then CDS may or may not enforce depending on the specifics.
Each of these has a solution. The solution involves explicit design rather than expecting CDS to handle every case.
Configuring CDS for an FSC implementation? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs CDS architecture, access-policy alignment, and audit configuration on every FSC engagement. Get in touch ->
See our Salesforce service page for the team.
