# Use cases for Agentforce in healthcare patient management

The fit is appointments, eligibility status, and logistics. It is not clinical judgement. Health Cloud holds the operational patient relationship, and the agent may read only what that user is already allowed to see.

**Published:** 2025-11-20
**Canonical:** https://synconai.com/agentforce-healthcare-patient-management
**Author:** SynconAI Architecture Team

## In short

Use Agentforce in healthcare for appointments, a stored eligibility status, and operational logistics. Not for clinical judgement. Health Cloud holds the operational patient relationship. The agent reads only what that user may see. Symptoms, medicines, and what a result means go to a person. In a clinic, escalation beyond scope is the product boundary.

## Sources

- **Agentforce: What is an AI agent?** (retrieved 2026-10-10)
  https://www.salesforce.com/agentforce/
  > When faced with complex issues beyond their scope, they can escalate the matter to human agents, ensuring that queries are resolved efficiently and accurately.
- **Agentforce: What is an AI agent?** (retrieved 2026-10-10)
  https://www.salesforce.com/agentforce/
  > These agents generate responses that are consistent with your company’s brand voice and guidelines using trusted business data, including Salesforce CRM data, external data from Data 360, and more.

## What to take away

- Book, move, or confirm an appointment that the scheduling rules can actually offer. Do not interpret why the visit was ordered.
- Read an eligibility status that is already stored. A blank field is a handoff, not a prompt to infer one.
- Give operational logistics from a maintained record: place, time, and who to call. Clinical preparation goes to a person.
- Symptoms, medicines, and results are a handoff with no suggested diagnosis attached. The agent does not assess urgency.

## The guide

A patient asks to move a Thursday appointment and, in the same message, describes a symptom. The agent confirms a new time that is not on the record, then adds that the symptom sounds routine. The clinic spends the next contact undoing both sentences. The slot was never offered by the scheduling rules. The clinical sentence was never in scope. The patient has now heard both from a channel that carries the organisation's name.

Healthcare patient management, for an agent, is a narrow operational job. The person wants a time, a status, or a place. They do not want a model to decide what is wrong with them, and the organisation should not offer that, including as a helpful aside after a booking that was otherwise fine.

Health Cloud holds the operational patient relationship: the appointments, the eligibility status you already store, and the logistics of the visit. The clinical record stays in the system of record your clinicians use. The agent does not reach into that record to interpret a note, a result, or a medicine list. It reads what the running user may see, and nothing else. A wider user, chosen so the demo can quote more of the chart, is a defect in the design rather than a shortcut in the build.

## Appointments

The agent may confirm a time that is already on the record, or collect the facts a scheduling Flow needs in order to book, move, or cancel. If the slot rules are deterministic, the Flow owns them. Which clinician, which site, which duration, which lead time, which days the service does not book: those are rules with the same output every time. The agent only works out what the person is asking, and then it calls the Flow. It does not reimplement the rules in the instruction because a patient phrased the request as a preference.

Stop when the Appointment is confirmed, or when the rules cannot offer a slot. Do not invent a time to be helpful. A promised arrival that is not on the record is a failure, because the clinic will spend the contact undoing it, and the patient will treat the promise as the booking. "We will try for Thursday" is already too much if Thursday was not returned by the Flow. Say that the request is with the scheduling path, and stop.

If the person adds a symptom while booking, hand that part off and do not comment on it. The booking can still complete, if the Flow can complete it from the facts that are operational. The symptom does not get a sentence. Not a reassurance, not a clarification, not a suggestion to mention it at the visit in words the agent has coloured. The handoff carries the patient's words. The reply to the patient stays on the appointment.

This is the same boundary as any other workflow with a right answer. The Flow owns the slot. The agent classifies the sentence. [Known-answer steps stay in Flow or Apex](/best-practices-automated-workflows-agentforce), and a clinic's booking rules are that kind of step even when the message around them is anxious.

## Eligibility status

Reading a status is allowed when the value is already stored and the running user is allowed to see it. Active, inactive, pending: say the value, say the date it was recorded if you store one, and stop. Quote the field. Do not translate it into an opinion about whether the visit will be paid.

If the field is blank, say you cannot see a status and hand the question to a person. Do not infer one from a similar patient, from a previous conversation, or from the fact that an appointment exists. An appointment on the record is not an eligibility status. A card number mentioned in an old Case is not an eligibility status. A blank field is a missing fact.

::: note
A missing status is not a prompt to be helpful. The safe sentence is short: the status is not on the record the agent can see, and a person will take the question. Anything longer starts to invent the field.
:::

Advising is not reading. "Should this procedure be covered", "will this plan pay", and "what should I enrol in" are not status checks. They are decisions. Salesforce's line is that agents escalate when the issue is beyond their scope. Answer the status if you can see it, then hand off the advice. Do not let the status sentence grow a second clause that recommends a course of action. The second clause is the advice, and it will be heard as the organisation's position.

A front-desk user and a specialised reviewer do not see the same fields. Run the agent as the user the channel is allowed to be, then test with a question that reaches for a field that user cannot see. The correct result is a refusal, not a fuller quote. Widening the user so the demo sounds informed teaches the agent to see past the clinic's own rules. Put shareable facts, such as a status the front desk is already allowed to say aloud, on the record that user can read. Do not borrow a reviewer's access for a reception channel.

## Logistics, and the benefits questions that are safe

Logistics means where to go, which desk, what time to arrive, and which number to call if they are lost. Those answers should come from a maintained record, not from a generated guess. If the site address is wrong on that record, fix the record. An instruction that says "be accurate about locations" will still quote the wrong address, faithfully, because the address is what retrieval returned.

Benefits questions that stay in bounds are status questions. Whether an enrolment is on file. Whether a card has been recorded. Whether a claim record shows a status you already store. Say the value and the date, if you store one, and stop. The moment the question becomes "what should I do about my care", or "is this the right plan for me", it is a handoff. A status can sit next to a decision in the same message. Answer the status. Hand off the decision. Do not let the decision borrow credibility from the status you were allowed to read.

Clinical preparation is not logistics. Fasting, stopping a medicine, or how to read a result is clinical, even when a pamphlet exists and even when the pamphlet is sitting in Knowledge. Pointing at the pamphlet and then explaining it is still advice. Summarising it is still advice. The summary will drop a caveat, or it will sound more certain than the pamphlet was, and the patient will follow the summary. Hand that question to a person. The handoff can name the pamphlet as a document a person may use. The agent does not become the person.

| The person asks | In scope if | Hand off when |
| --- | --- | --- |
| Confirm or move an appointment | A stored appointment, or a Flow that returns a real slot | The rules cannot offer a slot, or a time would have to be invented |
| Eligibility | The status is already stored and this user may see it | The field is blank, or the question asks what a plan should cover |
| Where to go, what time, which number | The answer is on a maintained record | The record is blank, or the question becomes how to prepare clinically |
| A benefit or a claim | The question asks for a status you already hold | The question asks what they should do about their care |
| A symptom, a medicine, a result | Never, including as a remark after a booking | Always, with their words attached and no suggested reading of them |

The table is the scope. A message that crosses a row gets the in-scope part done and the other part handed off. It does not get an averaged reply.

## What the agent must refuse

Refuse diagnosis, triage of symptoms, medicine changes, and any reading of a result. Urgency of symptoms is a clinical judgement. A sentence that begins "this sounds routine" is a defect, not a reassurance. So is "this sounds serious", "you should be fine until Thursday", and "that is a common side effect". Each of those is the agent assessing the person. The channel is not a clinician, and a careful tone does not make it one.

Refuse to rank options. "The morning slot is better given what you described" imports the symptom into the booking. Offer the slots the Flow returned, or say that none were returned. The reason the person prefers a morning is their business. The agent does not turn that reason into a clinical sorting of the diary.

The handoff is a Case or the queue your clinic already uses, with the patient's identity, the question in their words, and a clear note that no clinical answer was given. Do not attach a suggested diagnosis for the next person. Do not attach a suggested urgency. The next person is qualified to form both, and a line in the note will be treated as advice that has already been given, including by someone who only meant it as a hint. If your clinic already has words for how reception escalates a symptom, use those words. Do not improve them.

::: warn
A mixed message is the test that matters. Booking plus a symptom must produce a booking or a stop, plus a handoff, and no clinical sentence. If the symptom receives an adjective, the subagent is not fit to face a patient, however accurate the appointment time was.
:::

Write the refusals into the instruction the plan sees on every turn, not into a policy page the patient is expected to paste. The real message will not include your exclusions. It will include the symptom. [The instruction has to carry the refusal](/prompts-einstein-and-agentforce), because the utterance will not. Test with the policy absent from the user message. If the agent only behaves when the policy is in the utterance, the refusal is not real.

## How a clinic gets this wrong

Three shapes, and each is recognisable in a transcript.

The helpful close. The appointment is correct, and the last sentence comments on the symptom because the instruction said to be reassuring. Delete the reassurance. Reassurance about a symptom is clinical content. Operational politeness, such as confirming the site and the time, is not.

The inferred status. Eligibility is blank, the patient is anxious, and the agent says the enrolment is "probably active" because a card was mentioned last month. That sentence will be repeated at the desk as if it were the field. Say the field is blank.

The wide user. The front-desk agent can quote a result because someone copied a reviewer user to make a pilot impressive. Put the user back. Re-run the question. The pass is a refusal. A true result said to the wrong channel is still a failure of the boundary.

The work of leaving an agent inside a boundary this tight, including what has to stay true after the pilot, sits with the rest of the rollout questions in [what separates an Agentforce rollout that is still running in six months](/insights/agentforce-implementation-best-practices). In a clinic the boundary is not a tone. It is the list of sentences you are willing to have quoted back to you by a patient.

## Questions

### Can Agentforce tell a patient what their symptoms mean?

No. Symptoms, treatment, medicines, and results go to a person. The agent does not assess urgency and does not say a problem sounds minor, serious, or routine. If a booking message also describes a symptom, the agent may finish the operational booking and must hand the clinical part over without commenting on it. An adjective on the symptom is a failed test, even when the appointment time was right.

### What patient questions are in scope?

Appointments, an eligibility status already stored on the record, and operational logistics such as place, time, and the number to call. A benefits question is in scope only when it asks for a status you already hold. Advice about what a plan ought to cover, what to enrol in, or how to prepare clinically is not. A message that contains both a status question and a care question gets the status, then a handoff.

### Where does the patient relationship live?

Health Cloud holds the operational relationship the agent is allowed to use: appointments, the eligibility status you already store, and the logistics of the visit. The clinical record stays in the clinician's system. The agent reads only what its running user can see. It should not be given a wider user so that a demo can quote more of the chart. A front-desk user and a reviewer do not see the same fields, and the agent should not collapse that difference.

### What if eligibility status is blank?

The agent says it cannot see a status and hands the question to a person. It does not infer a status from another patient, from an old conversation, or from the fact that an appointment exists. A blank field is a missing fact, not a prompt to be helpful. "Probably active" will be repeated at the desk as if it were the stored value.

### How should a clinical question be handed over?

Open the path your clinic already uses, with the patient's identity and the question in their words. The note should say that no clinical answer was given. Do not attach a suggested diagnosis or a suggested urgency for the next person. That line will be treated as advice. If reception already has words for escalating a symptom, use those words rather than improving them.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Healthcare and life sciences (https://synconai.com/salesforce-healthcare-life-sciences).