Agentforce for Health's Prior Authorization Skill: What's Actually Pre-Built
Agentforce for Health markets its prior authorization capability as a pre-built skill: turn it on, point it at a patient record, and an agent checks eligibility, decides whether a procedure needs authorization, and submits the request. That framing is accurate for one layer of the system and misleading for the layer that actually determines whether the thing works in production. Before an architect signs off on this pattern, the question worth asking is narrower than “does it work” — it is “what, specifically, did the pre-built part pre-build.”
What Ships Pre-Built
The part Salesforce ships is the orchestration layer: an agent that can hold the conversation, decide when a procedure needs prior authorization, and call the right actions in the right order. Cloud4Good’s overview describes Agentforce for Health as running inside Agentforce 360, “integrated natively with Salesforce Health Cloud,” with the AI layer connecting to Data Cloud and care coordination workflows without separate management. The skill list is real and useful: eligibility checks, prior authorization submissions, appointment scheduling, referral coordination, care gap outreach, and benefits verification are all available as starting points rather than agents an architect has to design from a blank canvas.
That is a genuine head start on the part of the system that used to take the longest to get right: agent instructions, intent recognition, and the sequencing logic that decides which action fires when. It is not a head start on the part that decides whether the numbers in the case studies are achievable for your organization.
What the Case Studies Are Actually Measuring
Accelirate’s case study of a national payor is the clearest example available of what “working” looks like: prior authorization turnaround cut 50%, administrative effort on eligibility checks down 80%, verification that used to take hours now resolved in seconds. Read past the headline numbers and the case study names the mechanism directly. The agent performs “real-time API calls across eligibility, benefits, and coverage databases” and an “LLM-driven prompt analyzed benefit types, plan rules, and procedure codes to determine if prior authorization was needed.”
Both of those sentences describe integration that already existed. The speed gain comes from replacing a person who manually queried those systems with an agent that queries them programmatically. If those real-time connections to eligibility, benefits, and coverage databases are not already in place for your payer mix, the agent has nothing fast to call, and the 50% figure does not transfer. The case study is evidence that Agentforce is a good orchestrator on top of working data plumbing. It is not evidence that the plumbing comes with it.
The EHR Side Doesn’t Come Pre-Wired Either
The other gap sits upstream of Salesforce. HIT Consultant’s reporting notes that Agentforce “connects Salesforce Health Cloud to all major EHR systems, including Epic, Cerner, MEDITECH, and Allscripts” — but that connection happens at the EHR-integration level, not as a property of the prior authorization skill itself. A prior authorization agent is only as good as the clinical and coverage data it can see, and every one of those four EHRs models diagnoses, procedures, and coverage differently. HIT Consultant’s own framing captures the tension without resolving it: it notes that organizations can use the pre-built skills or construct new agents “from the ground up,” and that different hospitals and clinics “operate with distinct protocols” — without saying which parts of that protocol variance the pre-built skill actually absorbs. The honest answer is: the conversation logic absorbs it if you configure it to. The data mapping between your specific EHR instance and Salesforce does not configure itself.
A Partner Closes One Gap, Not All of Them
Salesforce has announced a partnership with Availity to integrate Agentforce for Health, and Availity’s own business is running one of the country’s largest healthcare clearinghouses. Read together, that points at a shared dependency worth crediting: payer connectivity is exactly the kind of infrastructure a platform vendor should provide once instead of every customer building their own EDI connection. But neither source spells out the mechanics of what gets automated and what doesn’t, and a clearinghouse relationship, however it is wired in, only ever handles the payer side of the transaction. It does not resolve which of your EHR’s procedure codes map to which payer’s authorization rules, and it does not tell the agent what to do when a payer lookup returns an ambiguous or partial match — a routine occurrence, not an edge case, in prior authorization data. Ask your Salesforce team to show you that mapping and that exception path before you trust the demo.
What We Would Do
Before enabling the guided setup, we map payer and EHR connectivity gaps first, not last: which payers in the organization’s actual mix already have working real-time eligibility and benefits connections, and which don’t. That map determines which patients the agent can serve on day one versus which still route to a person, and it is the single biggest determinant of whether the rollout looks like the case study or looks like a stalled pilot.
We also treat every agent-submitted prior authorization as a compliance event, not just a workflow step. Given the CMS interoperability deadlines already reshaping prior authorization on the payer side, an auto-submitted request needs the same audit trail a human-submitted one would: what data the agent used to decide authorization was needed, what it sent, and what came back. That logging is not part of the pre-built skill’s marketing copy, and it is not optional once the agent is making determinations that affect patient care timelines.
Finally, we treat the pre-built skill as the starting configuration for a build, not the finished build. The conversation and orchestration layer gets stood up fast because Salesforce already did that work. The data contracts between your EHR, your payer mix, and Health Cloud get the same architecture rigor they would need if there were no pre-built skill at all, because functionally, for that layer, there isn’t one.
None of this makes Agentforce for Health a bad starting point — it is a legitimately faster way to stand up the parts of a prior authorization agent that used to eat the most design time. The mistake is reading “pre-built skill” as “pre-built integration.” They are different claims, and only one of them ships in the box.