Salesforce has spent years positioning Agentforce, Einstein, and its growing library of AI features as the reason health plans should invest in the platform. That’s good marketing, but it skips the part that actually matters. The real value isn’t the AI sitting on top. It’s the architecture underneath.
Health plans that understand this are getting measurable returns. The ones chasing the AI features first usually end up with very little to show for it.
What Health Plans Actually Look Like on the Inside
Here’s the operational reality at most payer organizations: data is everywhere and actionable nowhere.
A member calls the service line. The agent opens four systems to piece together who they’re talking to: demographics from the enrollment platform, claims history from the adjudication system, open cases from whatever the care management team is using, prior auth status from the UM tool. None of it talks to each other. The agent is the integration layer. Every single call.
Care managers are working out of spreadsheets because the care management platform doesn’t have a clean view of HEDIS gaps alongside the member’s open cases and recent touchpoints. So they built their own, in Excel, in 2026.
The interoperability team is manually pulling data to meet CMS reporting requirements because connecting their core systems to anything external requires a multi-year IT project.
This isn’t a technology problem. Every one of those platforms has an API. The problem is that nobody has built a single, coherent record of the member that everything else hangs off of.
That’s what Salesforce Health Cloud actually is, when you implement it right.
The Data Model Is the Product
Salesforce Health Cloud is built around a person-centric data model. At its core: every interaction, every case, every care gap, every authorization, every call belongs to a member record that any authorized user can see, in full, in real time.
This sounds obvious. It isn’t. Most health plan technology is built around transactions (a claim, an authorization, an enrollment event), not around the member as a continuous entity. The result is that member data exists in dozens of discrete places, none of which have a complete picture.
When Health Cloud is implemented well, you get:
- A single member record that surfaces across lines of business without manual reconciliation
- Care management workflows built into the same environment where service reps are working cases, so nothing falls through the handoff
- A complete interaction history (calls, cases, care plans, outreach) that any team member can see before they engage
- HEDIS gap data, risk scores, and care plan status visible to whoever needs them, when they need them, without a data pull
That’s not a feature. That’s a different way of operating. And it changes what AI can actually do downstream, once the foundation is built correctly. For an overview of the practical implications of that shift, see The Expensive Misconception About Salesforce Health Cloud.
Why AI Needs This Foundation First
Salesforce’s Agentforce for Health is genuinely interesting. The March 2025 announcement introduced pre-built agent skills for real-time prior auth through Availity, AI-assisted benefits verification, automated member outreach, and contact center summaries. The March 2026 follow-up added six new agents for providers and payers, with integrations from HealthEx, Verily, and Viz.ai extending the platform’s reach further into clinical operations.
But every one of those capabilities depends on clean, connected, complete member data. An AI agent that runs eligibility checks on an incomplete enrollment record gives you a wrong answer, faster. An agent that surfaces care gaps from a HEDIS data set that’s three months stale isn’t helping anyone.
The plans that will actually get value from Agentforce are the ones that already did the unglamorous work: the data model, the integration layer, the workflow configuration, the governance. AI adds speed and scale on top of a foundation that already works. It can’t build that foundation itself.
Health plans that skip to the AI features first are going to learn this the hard way. The governance considerations that come with deploying AI at scale are equally important. For more on that, see Everyone Can Build. Now What?.
What Getting This Right Looks Like
The health plans we’ve seen use Salesforce most effectively share a few things in common.
They treated implementation as a process design project, not a software deployment. They mapped their actual member workflows, how a care manager works a gap closure campaign, how a service rep handles a complex billing dispute, then built Salesforce around those workflows instead of the other way around.
They invested in the integration work. MuleSoft, direct API connections, or both, whatever it took to get the claims system, the enrollment platform, and the care management tools talking to Health Cloud. That’s where most of the value lives. It’s also where most implementations cut corners.
They didn’t stop at go-live. The first version of a workflow is never the right version. The plans that are getting ROI have someone continuously tuning configuration, building out reporting, and extending the platform as needs evolve. This is an operating-model change, not a software rollout.
Where to Start
Salesforce has built something genuinely useful for health plans. But the pitch that leads with AI agents and prebuilt skills skips the hard conversation: none of that works without a foundation that most health plans don’t have yet.
The data model is the investment. The AI is what you get to do with it later.
If your Salesforce environment isn’t performing the way you expected, the issue is almost certainly the foundation, not the features. That’s where we start.
Let us show you where.
Start with Salesforce Health Cloud assessment →
i2 Health works with health plans on Salesforce implementation, optimization, and AI readiness: starting with the data foundation.
Frequently Asked Questions
Q: We’re already live on Salesforce Health Cloud. Do we need to rebuild it to get the data model right?
It depends on what got built on top of it.
If you’re running close to standard, no. The core objects are already sitting in your org. What’s usually missing is the plumbing: claims, enrollment, and care management actually feeding the member record instead of sitting next to it. That’s integration and configuration work layered on what you have. Not a teardown, and nobody should be quoting you one.
But if you bought Health Cloud licenses and then built a heavily custom solution on top of them, which is very common, real rebuild work is on the table. Getting back to standard is what lets you use the platform you’re already paying for: the healthcare accelerators, the roadmap, the AI capabilities. Custom objects inherit none of that. So the first move is an honest read on how far your org has drifted from standard, because that answer sets the scope of everything else.
Q: How does Salesforce Health Cloud integrate with Facets, QNXT, or other core admin systems?
Through a preferred middleware, like MuleSoft is the shortest path. It ships with healthcare accelerators that translate what your core speaks into FHIR R4, which is what Health Cloud works in natively, and it’s governed inside the same platform as everything else you’re building. Less to stitch together, less to maintain.
You’re not locked into it, though. If you’ve already standardized on Boomi, Informatica, or an internal integration layer, we’ll build against that. The mappings and the data contracts matter more than the vendor.
What doesn’t change either way: you’re not replacing or migrating off Facets or QNXT. Your core keeps adjudicating exactly where it adjudicates today. The integration just gets that data flowing into the member record so a rep isn’t toggling five systems mid-call. Worth saying plainly, this is the part of the build most implementations shortchange, and it’s where the value gets left behind.
Q: How long does a Salesforce Health Cloud implementation take before it delivers value?
It depends on the shape of your org, and anyone quoting you a date before they’ve looked at it is guessing.
Ninety days to a first production workflow is realistic when you’re near standard, your core-system data is accessible, and you scope to one use case like member services or care management. Ninety days to restructure a custom org back to standard, stand up new core-system integration, and layer AI on top is not. That’s a bold number, and it’s the kind of promise that becomes a stalled program in month six.
Two variables set your timeline: how far your configuration has drifted from standard, and how clean and accessible your core-system data is. Pressure-test both before anyone shows you a schedule.
