Use cases for Agentforce in healthcare patient management

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, 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.

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 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.

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, 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. 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.