3. Full Article

Salesforce Proactive Service offers an appealing promise for health insurers: identify a service need before the member calls, send relevant outreach, and guide that member to resolution with Agentforce.

The difficult part is not sending the message. It is making the entire journey work.

Salesforce's architecture crosses Data 360, Salesforce Core records, Service Campaigns, Omni-Channel, Experience Cloud, Agentforce, and Enhanced Chat. If any link is incomplete, the result can look deceptively normal. A campaign may finish with zero members. Outreach may appear late. A chat invitation may not load. The agent may display raw variables, fail user verification, or enter a conversation without enough context to resolve the issue.

For a health plan, those are not merely technical defects. A badly timed or irrelevant message can deepen frustration in a member journey already shaped by cost concerns, claims uncertainty, and low trust.

The practical response is to treat proactive service as a controlled data-to-resolution system, not as a messaging campaign. Before launch, require the whole chain to pass eight release gates.

Why proactive service matters now

On October 13, 2026, Salesforce highlighted a new wave of Service Cloud capabilities and described disconnected voice, digital, AI, and CRM systems as a barrier to deploying AI. That diagnosis is especially relevant to proactive service: outreach only works when signals, identity, channels, actions, and operational ownership remain connected.

The need is also visible in the payer market. J.D. Power reported in May 2026 that only 30% of commercial health plan members considered their plan a trusted partner in health and wellness. Its study identified claims resolution as a major opportunity: members who described claims resolution as excellent reported materially higher satisfaction than those with weaker experiences.

KPMG's 2026 member-experience analysis similarly points to fragmented journeys, disconnected data, reactive claims correction, and unclear communications. Proactive service can address moments such as missing claim information, an incomplete enrollment step, an upcoming administrative deadline, or a status change that is likely to generate a call. But automation creates value only when it completes a useful outcome and does not introduce another disconnected interaction.

Understand the actual Salesforce journey

Salesforce describes Proactive Service in four stages:

  1. Detection: Data 360 evaluates customer or product signals and builds a dynamic watchlist.
  2. Planning: The organization associates that watchlist with a resolution path, such as a service automation or an Agentforce Service subagent.
  3. Outreach: The system sends an SMS or email notification that starts the interaction.
  4. Fulfillment: The member enters an Experience Cloud journey, where the Proactive Service Campaign Handler passes context to Agentforce or a guided process.

That description reveals the implementation risk. A successful message delivery proves only one part of the service. The real acceptance test begins with the source event and ends with the member's record, task, or case reaching an accurate final state.

Gate 1: Choose a narrow, provable service outcome

Start with a journey that has one observable trigger, one defined audience, and one bounded resolution.

Good early candidates might include requesting a missing administrative document, explaining a claim-status change, confirming receipt of an item, scheduling a non-clinical service appointment, or guiding a member through a routine account action. The final choice should be based on actual contact volume, member effort, repeat-call patterns, operational cost, and risk.

Avoid beginning with an outcome that depends on ambiguous source data, clinical judgment, complex benefit interpretation, or several downstream teams. A compelling demo is not evidence that a journey is ready for unattended outreach.

Define success before configuration begins. “Message sent” and “session contained” are weak outcomes. Prefer measures such as:

  • required document received and matched to the correct case;
  • claim-status question resolved without repeat contact within a defined period;
  • appointment successfully scheduled or rescheduled;
  • member transferred with verified identity and complete context;
  • case created, routed, and reconciled when self-service cannot finish the task.

Gate 2: Prove eligibility and member identity

Salesforce states that Proactive Service requires a valid Salesforce Core Contact ID. If a contact ID is not found, the system removes that person from the member list. A Data 360 query that finds no eligible members can also cause a campaign to complete with zero impacted members.

This means an empty campaign is not automatically evidence that no one needs help. It may indicate an identity or mapping failure.

For each target member, validate:

  • the source signal belongs to the intended person or account;
  • identity resolution maps the signal to the correct Core Contact;
  • duplicate, merged, and household records behave as expected;
  • contact details are current and appropriate for the selected channel;
  • communication preferences, consent, suppression, and jurisdiction-specific policies are applied;
  • the member can complete any required verification without being trapped in a loop.

Health plans should have privacy, compliance, and legal owners review the use case, data fields, message content, authentication path, retention, and escalation policy. Salesforce configuration does not by itself establish that an outreach practice is appropriate or compliant.

Gate 3: Validate the signal, data model, and timing

The source event must survive every transformation between the operational system and the service journey.

Salesforce currently documents an important Data 360 constraint: Proactive Service supports a DMO only when it comes from a single Data Lake Object and uses a single unique attribute as its primary key. That can conflict with designs that depend on blended sources, compound identity, or complex derived records.

Build a field-level trace for the pilot:

  • source system and event;
  • ingestion time and failure handling;
  • Data Lake Object and supported DMO;
  • primary key and Core Contact mapping;
  • calculated insight or threshold;
  • detection rule and flow;
  • Service Campaign Member creation;
  • context passed into the member experience;
  • final record update after resolution.

Timing also needs explicit acceptance criteria. Salesforce says detection can take five to ten minutes after a Data 360 event, DMO synchronization is asynchronous, and outreach runs on a schedule two hours after a campaign launches. Those are expected behaviors, not necessarily incidents. The business team must decide whether they are suitable for the use case and ensure dashboards do not mislabel normal latency as failure.

Gate 4: Make a deliberate channel-version decision

Salesforce's current guidance says Proactive Service supports Enhanced Chat v1 only. Enhanced Chat v2 and other messaging channels are not compatible with this capability. Salesforce separately positions v2 as the newer experience with improved performance and support for custom Lightning Types.

That creates an architectural choice. A team can select v2 for a modern inbound experience and later discover that its planned proactive flow needs v1. Salesforce also recommends against mixing v1 and v2 on the same domain because messages may fail to appear in v1.

Before building, document:

  • the required proactive and inbound use cases;
  • which version supports each required feature;
  • whether the organization already has a v1 or v2 deployment;
  • domain and coexistence constraints;
  • pre-chat, verification, custom-content, survey, and accessibility needs;
  • the migration assumption if Salesforce expands compatibility later.

Do not treat the channel version as a cosmetic decision. It determines whether the journey can launch and whether other service experiences remain coherent.

Gate 5: Bound what Agentforce can know and do

The agent should receive the minimum verified context needed for the task and only the actions required to complete it.

For each action, specify:

  • the agent identity and effective permissions;
  • the caller or member identity used for authorization;
  • allowed records, fields, and systems;
  • read-only versus write behavior;
  • validation and approval requirements;
  • idempotency and duplicate-action protection;
  • timeout, retry, and error behavior;
  • a deterministic human handoff or case-creation path.

The welcome message and context variables deserve testing too. Salesforce says raw variable names can appear when URL or Messaging Session context is missing. A journey that starts with broken personalization immediately signals that the system does not understand the member's situation.

For regulated or sensitive service, keep high-consequence decisions out of the autonomous path unless the organization has explicitly designed, tested, approved, and monitored that authority. Proactive service is well suited to detecting and guiding administrative work; it should not be allowed to drift into clinical, coverage, or legal judgment through vague prompts.

Gate 6: Test one complete member journey

Salesforce's own test procedure begins by changing source data to cross a calculated-insight threshold. It then requires a tester to enter the Experience Cloud site, verify the chat invitation, interact with the Agentforce Service Agent, and confirm the Service Campaign Member status update.

Use that as the minimum skeleton, then add business-critical cases:

  • correct member and qualifying event;
  • event below the threshold;
  • missing or duplicate Core Contact;
  • stale, late, or corrected data;
  • opted-out or invalid destination;
  • successful verification and failed verification;
  • agent resolves the task;
  • agent cannot resolve the task and hands off;
  • downstream system times out after the member acts;
  • member returns through another channel;
  • repeated event does not create a duplicate action;
  • standard, delegated, caregiver, or authorized-representative personas where applicable.

Reconcile the complete outcome after each test. Confirm not just what the member saw, but also the campaign status, CRM record, downstream transaction, audit evidence, handoff context, and reporting data.

Gate 7: Measure the funnel, not just the agent

Agent Analytics can help teams inspect sessions, actions, performance, quality, trust, cost, and ROI. However, an agent dashboard alone cannot reveal every failure before the conversation starts.

Build a service funnel that separates:

  1. qualifying source events;
  2. events ingested successfully;
  3. members meeting the detection rule;
  4. members matched to valid Core Contacts;
  5. campaign members created;
  6. messages attempted and delivered;
  7. invitations displayed;
  8. members verified;
  9. sessions started;
  10. tasks completed, handed off, abandoned, or failed;
  11. final records reconciled;
  12. repeat contacts and downstream outcomes.

This makes silent loss visible. If 10,000 records meet the business condition but only 7,000 become campaign members, optimizing the agent's language will not solve the primary problem.

Use a balanced scorecard. Containment can be useful, but it should not outrank task accuracy, verified completion, safe escalation, member effort, repeat-contact reduction, complaints, and cost per successful outcome.

Gate 8: Establish a live operating model

Proactive Service needs named owners across service operations, Salesforce, Data 360, identity, integration, Experience Cloud, privacy, and business process teams.

Salesforce currently notes that campaigns do not have an automatic end date or completion status. Organizations therefore need an explicit lifecycle procedure covering launch approval, monitoring, pause criteria, closure, residual members, and evidence retention.

The runbook should answer:

  • Who can pause outreach immediately?
  • What happens when the source data is wrong?
  • How are members already contacted handled after a correction?
  • Which team owns empty campaigns, identity loss, delivery failure, verification errors, agent failures, and downstream write failures?
  • How long can each stage remain incomplete before escalation?
  • How are abandoned and transferred interactions reviewed?
  • How are changes to flows, DMOs, prompts, actions, routing, and site components released and regression-tested?

Start with a controlled cohort. Expand only after the organization has observed at least one complete business cycle and can explain every material drop between eligibility and resolution.

What this means for healthcare, insurance, and nonprofits

Health insurers: Claims and benefit-administration journeys can generate high call volume and anxiety. Use proactive service to reduce uncertainty around bounded administrative steps, while preserving clear human access for disputes, exceptions, vulnerable members, and anything requiring judgment.

Healthcare providers: Scheduling, referral-document collection, service preparation, and administrative follow-up can be candidates. Keep clinical advice and urgent-care decisions outside the workflow unless they are governed by an appropriate clinical system and qualified review.

General insurers: First-notice follow-up, missing-document collection, appointment coordination, and claim-status updates may fit. Test catastrophe-volume conditions, delegated authority, fraud flags, and adjuster handoff rather than assuming a routine pilot represents peak operations.

Nonprofit foundations: Grant-document reminders, applicant-status updates, beneficiary scheduling, and donor service can reduce manual workload. Salesforce's current lack of multilingual translation in Proactive Service may be a decisive constraint for multilingual communities, so provide accessible alternatives and do not automate around that gap.

Make proactive service earn the right to scale

The strongest proactive service program is not the one that sends the most messages. It is the one that can prove why each person was selected, what context was used, what action was authorized, whether the issue was resolved, and what happened when automation was not enough.

That is the standard health insurers should apply before member outreach: one narrow outcome, one traceable chain, one accountable operating model, and evidence from trigger through resolution.

A focused next step with Yuniq

Yuniq's Salesforce practice provides implementation, customization, consulting, and ongoing support. Ask Yuniq to assess one high-value proactive-service journey across Data 360, Core Contact identity, Service Cloud, Omni-Channel, Experience Cloud, and Agentforce, then turn the eight gates in this article into a pilot acceptance plan. Explore Yuniq's Salesforce services .