Interaction Summaries & Confidentiality Controls in FSC

What Interaction Summaries Are (and Why They Matter)

An Interaction Summary is a structured record of a client meeting, call, email exchange, or video conference. Financial Services Cloud — officially rebranded as Agentforce Financial Services in 2026, though the product is still universally referred to as FSC in the documentation, object model, and Trailhead curriculum — introduced the feature in Spring ’21 and exposed the InteractionSummary object in API version 51.0. The capability is included in Enterprise and Unlimited editions of FSC.

Up to that point, financial-services teams logged meetings with standard Activities — Tasks and Events. That model breaks down quickly in regulated work. A managing director discussing a confidential merger doesn’t want the Task automatically rolled up to senior leadership through the role hierarchy. A wealth advisor meeting with a celebrity client doesn’t want the meeting note’s contents visible to anyone who can see the parent account. Activities can’t easily separate those concerns because they inherit sharing from their parent.

Interaction Summaries solve that with three architectural moves: meetings live as independent Interaction records with their own attendees, notes live as InteractionSummary child records with their own sharing model, and the two together can be governed by Compliant Data Sharing (CDS) for precision, role-based access on a per-record basis. A Confidentiality Type field on each summary tells users (and admins building reports and flows) which records need that extra layer of control.

Interaction Summaries vs. Activities

The exam regularly tests the practical differences between these two ways of capturing client meetings. Most of the confusion comes from organizations that have used Activities for years and want to know what they gain by switching. Here is the verified comparison from Salesforce documentation.

For a wealth advisor logging a quick check-in call, Activities are fine. For an investment banker capturing pricing discussions across a multi-week M&A negotiation, Interaction Summaries are the right model — the data needs to persist, needs to be selectively shareable, and needs to live alongside multiple deal and account contexts.

The Data Model: Interaction, Summary, Attendee, Participant

Four objects form the spine of the feature, with several supporting junction objects connecting them to deals and accounts. Understanding which object plays which role is essential for everything that follows.

The four core objects

Supporting junctions

The Interaction Summaries data model also ships with junction objects that tie meetings and notes to broader FSC context: InteractionDeal and InteractionSummaryDeal link records to FinancialDeal; InteractionRelatedAccount and InteractionSummaryDiscussedAccount capture additional accounts referenced during a meeting; ParticipantRole is the contextual role used by CDS when granting access (Lead Banker, Analyst, Compliance, etc.).

Independent but linked sharing

Because Interaction and InteractionSummary are separate objects, they share independently. Granting a user access to an Interaction does not grant them access to its summaries. Granting access to a summary does not back-propagate access to the parent interaction. This is intentional: the meeting may be widely known while the detailed notes remain restricted.

Confidentiality Type: The Label That Triggers the Lock

The Confidentiality Type field on the Interaction Summary classifies the sensitivity of the record. Salesforce documentation explicitly references the Confidential value as the threshold that, when combined with Compliant Data Sharing, restricts the record to its named Interaction Summary Participants. The picklist is admin-configurable, so organizations can extend it with their own labels (Internal, Restricted, MNPI, etc.) as part of an org-wide data-classification scheme.

On its own, the field is metadata. Setting Confidentiality Type to Confidential without CDS enabled does not magically hide the record — it just labels it. The lock comes from how CDS is configured, the org-wide defaults (OWD) on the Interaction Summary object, and whether Role Hierarchy–Based Sharing is disabled. Confidentiality Type is the signal; CDS is the enforcement.

Where Confidentiality Type shows up

Confidentiality Type appears in three places that admins should know about:

• On the record page as part of the Interaction Summary detail fields.
• In the Interaction Summaries Lightning component as a quick filter alongside title search.
• In sharing logic — admins typically build flow or validation rules that require Interaction Summary Participants to be added when Confidentiality Type = Confidential.

Compliant Data Sharing for Interaction Summaries

Compliant Data Sharing is the FSC capability that grants precise, role-based access to a specific record. Unlike sharing rules (which target large groups of records) or role hierarchy (which propagates up an org chart), CDS lets a user assign a contextual role to a participant on a single record. The role drives the access level.

CDS currently supports five standard targets: Account and Opportunity (standard objects), and Financial Deal, Interaction, and Interaction Summary (FSC objects). Since the Summer ’22 release, CDS also supports custom objects, which means partner-built or org-specific objects can opt into the same model.

How CDS interacts with OWD

CDS creates entries in the object’s share table only when a participant’s role grants access that exceeds the organization-wide default. If the OWD on Interaction Summary is Private and a participant role grants Read access, CDS creates a share record. If the OWD is already Public Read/Write, CDS doesn’t need to add anything — the user already has that access.

CDS vs. manual sharing and account teams

Account teams and opportunity teams let an end user grant access by directly specifying a target user’s access level — closer to manual sharing. CDS is different: the end user assigns a contextual role to a participant, and the access level is automatically derived from how that role is configured at the org level. This consistency is the whole point. Compliance defines the roles and their access; users assign the roles to participants. Users never set raw access levels themselves, which is exactly what regulators want to see.

Because CDS participant tables are themselves Salesforce objects, you can apply validation rules, approval processes, and Flow to enforce business policies around how participants are added or modified. A common pattern is to require approval from a compliance manager before certain roles can be added to a Confidential Interaction Summary.

Setup: Enabling Interaction Summaries

Setup is a two-phase exercise. Phase one enables the feature and surfaces the components. Phase two wires Compliant Data Sharing in. If you only need notes that share like everything else in the org, phase one is enough.

1. Enable the Interaction Summary setting. In Setup, search for Interaction Summary Settings and toggle Interaction Summary to enabled. This unlocks the related Lightning components and underlying objects.
2. Add the Interaction Summaries component to the Home page and Account record pages via Lightning App Builder. On the Home page, users see every summary they have access to. On an account, they see only the summaries related to that account.
3. Add the Interaction Attendees component to the Interaction Record Page. Without this, users can’t capture multiple internal and external attendees on a single interaction — they fall back to logging single-attendee Activities.
4. (Optional) Disable Role Hierarchy–Based Sharing for Interactions and Interaction Summaries. Setup → Interaction Summary Settings exposes two toggles. Disabling these prevents senior leadership from auto-inheriting access to sensitive interactions through the role tree.
5. Configure org-wide defaults for the Interaction Summary object. For CDS to grant access beyond what users already have, OWD typically needs to be set to Private or Public Read-Only.

Setup: Wiring CDS to Interaction and Interaction Summary

Phase two assumes the broader CDS prerequisites are already in place (org-wide defaults set, Participant Roles defined, Compliant Data Sharing Manager and User permission sets assigned to the right users). With those done, enabling CDS for Interaction Summaries is a focused set of steps.

1. Open Object Enablement Settings. In Setup, search for Object Enablement Settings. The page lists every object currently supported by CDS.
2. Enable Interaction for CDS. This adds the participant table for interactions and exposes the Manage Participants component on Interaction record pages.
3. Enable Interaction Summary for CDS. Same effect, applied to the summary object. Both must be enabled if you want independent participant-based sharing on both records.
4. Define Participant Roles for each object. Typical FSC roles include Lead Banker, Analyst, Compliance Reviewer, Coverage Team. Each role has a default access level (Read, Read/Write, Edit).
5. Add the Manage Participants component to the Interaction Record Page and the Interaction Summary Record Page. Configure participant-type suggestions in each (see below).

The Manage Participants Component

The Manage Participants Lightning component is how end users add CDS participants to a record without leaving the page. It supports adding multiple participants at once and surfaces context-aware suggestions to speed things up.

Smart suggestion sources

When configured on a record page, the component pulls suggested participants from related records based on the configured suggestion types:

Each suggested participant arrives with a role picker; users select the contextual role for that participant, and the component creates the participant record. Behind the scenes, the platform writes to the participant table (InteractionSummaryParticipant or its Interaction equivalent) and the corresponding share table gets a row with RowCause = 'CompliantDataSharing'.

Participants can be individual users or public groups. Group support matters because compliance teams, deal teams, and coverage teams change membership frequently — adding a group participant means new team members automatically inherit the right access without anyone touching the participant record.

Participants vs. Attendees — don’t confuse them

Attendees and Participants are different concepts on the same object hierarchy. Attendees are the people who were at the meeting (Internal Users or External Contacts) — descriptive metadata. Participants are users granted access through CDS — sharing metadata. A user can be both. A contact (external attendee) cannot be a participant because they are not a Salesforce user.

What’s evolved through Spring ’26

The core Interaction Summary and CDS model has been stable since Spring ’21, but Salesforce has layered several productivity enhancements on top. The behaviors below are live as of the Spring ’26 release and worth knowing whether you’re configuring a new org or auditing an existing one.

• Auto-created Interaction Participants (Spring ’24). Interaction Participant records are generated automatically for event attendees who are internal Salesforce users and have the Use Compliant Data Sharing permission. Before Spring ’24, admins or end users had to add these manually.
• Calendar sync into Interactions (Spring ’23 onward). Admins can enable a user’s Microsoft or Google account, via Einstein Activity Capture, to automatically sync calendar events into Interaction records — eliminating double-entry between Outlook or Google Calendar and Salesforce. Events not organized by Salesforce users can also sync, with a designated Salesforce user as the owner.
• Spring ’26 product context. Spring ’26 didn’t change the Interaction Summary or CDS data model, but Financial Services Cloud is now officially marketed as Agentforce Financial Services, and Spring ’26 AI capabilities (Financial Advisor Agent, Banker Agent, Banking Service Assistance) can now draft, summarize, or surface insights from Interaction Summary records as part of meeting prep workflows.

How the Sharing Layers Stack Up

Salesforce sharing is layered. CDS doesn’t replace any layer — it sits alongside them. Reading the layers in order helps when troubleshooting why a particular user can or can’t see a particular Interaction Summary.

When a user reports they can’t see a Confidential summary they should be able to, walk the layers in order. The most common failure mode isn’t CDS — it’s a missing object-level Read permission on Interaction Summary itself.

Patterns Across Wealth, Banking, and Insurance

Interaction Summaries shipped first for investment banking and CDS-heavy use cases, but the feature serves every FSC subvertical. The differences are in how teams use Confidentiality Type and CDS, not whether they should.

Investment banking and M&A

This is the canonical scenario. Coverage teams and CIB (corporate investment banking) groups discuss material non-public information that, if leaked to the capital-markets side of the firm, would trigger insider-trading concerns. Confidentiality Type = Confidential plus CDS plus a hard Chinese-wall participant strategy keeps the data segregated. Role hierarchy–based sharing is almost always disabled here.

Wealth management

Advisors use summaries to capture meeting notes across multi-generational households. The bulk of summaries don’t need confidential treatment, but conversations about estate planning, divorce, health issues, or beneficiary disputes do. Confidentiality Type is often used as a soft signal here, with CDS engaged only for flagged records.

Retail and commercial banking

Branch staff log conversations with private banking clients, board members, and employee accounts. The risk isn’t insider trading — it’s that not every teller and assistant manager needs visibility into the CEO’s checking-account discussion. CDS with the right participant roles keeps those notes visible only to relationship managers and authorized service reps.

Insurance

Carriers use Interaction Summaries for underwriting calls, claims discussions, and high-net-worth policy reviews. The Confidentiality Type field maps cleanly to insurance data classification policies, and CDS handles the participant-based sharing that compliance regulations like NAIC model laws expect.

Common Pitfalls and Best Practices

Enabling without a plan

The Interaction Summary setting can’t be turned off. Don’t enable it in production until you’ve decided which subverticals and which user populations will use it, and which won’t. A common mistake is to enable it broadly, leave Confidentiality Type with its default values, and then face a long cleanup when the picklist needs standardization months later.

Forgetting to disable Role Hierarchy–Based Sharing

If MNPI handling is the goal and Role Hierarchy–Based Sharing is left on, every executive above the deal team in the role tree automatically sees the records. This silently breaks the entire compliance story. Disable both toggles (Interaction and Interaction Summary) explicitly during setup.

Confusing Attendees with Participants

External attendees (Contacts) cannot be Participants because they’re not Users. New admins often spend hours trying to figure out why a client can’t see the meeting notes — they can’t, by design. If external access is required, that’s an Experience Cloud problem, not a CDS problem.

Skipping OWD configuration

CDS only adds rows to the share table when the participant role grants more access than the OWD. If OWD is Public Read/Write, CDS effectively does nothing — every user already has the access. For CDS to do meaningful work, OWD on Interaction and Interaction Summary should be Private (or Public Read-Only at most).

Treating Interaction and Summary sharing as linked

They aren’t. If a user needs both the meeting record and its notes, they need to be a participant on both. Build that into your training and your Flow automation. A common pattern is a Flow that mirrors participants from the Interaction onto its summaries, or vice versa, when a record is created.

Not testing in a sandbox

CDS interactions with sharing rules, role hierarchy, OWD, and FLS produce edge cases that are difficult to reason about on paper. A full-copy sandbox with realistic data is the only way to validate the configuration before production rollout. The pre-delivery checklist for any CDS-enabled object should always include scenario testing across user profiles.