Goldfinch Health runs a national surgical-recovery care program: nurses guiding patients through preparation and recovery around 15,314 surgeries managed in their Salesforce org. For years, the conversations that drove that care happened somewhere else — a standalone patient-messaging vendor whose threads never touched the patient record. A nurse deciding how to respond to "my incision looks red" had the message in one tab and the surgery, care plan, and history in another.
We replaced the vendor with real-time chat built inside Salesforce on Platform Events. Today that system has managed 100,000+ patient messages, serves 51 active users, and runs as the front door of the care program. This is the architecture, the migration, and the honest limits — the article we wish had existed when we scoped it.
The buy-vs-build decision, without the religion
The default move is to buy another tool. Patient-messaging vendors are good products; the previous one worked fine as a messaging app. The problem was structural, not functional: every message lived outside the system of record. No automation could react to a patient going quiet. No report could connect message volume to surgical outcomes. Staff swivel-chaired between the messaging tab and the CRM tab, and context died in the gap.
We framed the decision as three questions:
- Where does the operational truth live? For Goldfinch, Salesforce already held the patient, the surgery, and the care workflow. Messaging was the only major surface outside it.
- Does message data need to drive automation? They wanted unread-message escalation, care-team routing, and reporting — all trivial when messages are records, all integration projects when they are not.
- Can the platform actually deliver the experience? Real-time delivery, notifications, attachments, read receipts. This is where most teams assume Salesforce falls short — and where Platform Events change the answer.
Three yeses meant build. If your answers differ — if the CRM is not your operational spine, or messaging never needs to trigger workflow — a vendor tool is still the right call, and we say so in the FAQ below.
The architecture: one object, one event, two subscription paths
The design is deliberately small. Chat messages are records on a custom Message__c object — which means sharing rules, reporting, automation, and retention policy all come for free. A trigger on insert publishes a dedicated chat Platform Event carrying the message payload and thread context. The event bus does the real-time work.
Subscription is where healthcare chat gets architecturally interesting, because the two audiences live in different runtimes:
- Nurses, inside Lightning Experience: a console LWC subscribes through
lightning/empApi, the supported module for internal apps. New messages appear instantly, with desktop notifications so a nurse working another patient's record never misses an inbound message. - Patients, in an Experience Cloud portal:
lightning/empApiis not available in Experience Cloud sites — a limitation that surprises most teams mid-build. The patient-facing component subscribes through a CometD client loaded as a static resource, with its own session and reconnection handling.
On top of that spine sit the features that make it feel like a modern messaging app rather than a Chatter clone: read receipts written back to the message records, and attachment support that converts HEIC photos to JPEG in the browser before upload — because post-surgical patients photograph incisions with iPhones, and a nurse on a Windows console needs to open what they send.
Failures are records too. A dedicated chat error-log object captures anything that goes wrong in publish, subscribe, or delivery, because in a clinical channel the worst failure mode is the silent one. That discipline — and continuous production iteration since go-live — is why the care team trusts the channel enough to run intake through it.
The migration: go-live with history, not a blank slate
A chat system that launches empty is a chat system nobody trusts. Nurses needed the previous years of conversation context on day one, so before go-live we wrote a Python ETL that exported the full message history from the previous patient-messaging vendor, transformed it into Message__c shape — threads, timestamps, authorship mapped to Salesforce identities — and loaded it through Data Loader. When the first nurse opened the new console, every patient's thread was already there.
That is also why we report the headline number carefully: the 100,000+ messages under management include that migrated history alongside everything sent since go-live. It is the corpus the care team works from every day — not a claim that every message flowed through the new pipes — and the distinction matters if you are using numbers like this to size your own build.
The escalation rail: built, honest status included
Chat only works if patients read it, so we built the next rung of the ladder: when a message sits unread past a threshold, a Queueable makes a Twilio callout to send an SMS nudge, with consent handling in front of it. Full candor: this shipped as a built capability, and the care team runs chat-first today — the SMS rail has seen only token production use so far. We include it because the pattern is sound and the code is deployed, and we label it because a case study that blurs "built" and "battle-tested" is not one you should trust.
The companion event: who looked at this record?
Real-time messaging was the first Platform Event we authored in this org; the second answers the question every healthcare compliance conversation eventually reaches. An invisible LWC on the patient record page publishes an access event on open and close, and a trigger persists it for audit reporting — 34,860 access-audit events logged to date. Two authored Platform Events, two very different jobs, one pattern: publish an event, let subscribers do the writes.
The numbers, and where they come from
| Measure | Value | Source |
|---|---|---|
| Patient messages managed | 100,000+ (includes migrated vendor history) | Org record count, July 2026 |
| Active users | 51 | Org query |
| Surgeries managed in the same org | 15,314 | Org record count |
| Access-audit events logged | 34,860 | Org record count, July 2026 |
| Authored Apex classes / LWCs on the project | 166 / 59 | Code audit |
| Authored Platform Events | 2 | Code audit |
Every figure is a count from an org query or a code audit — never a patient, never an extrapolation. The chat build sits inside a broader platform engagement, which is why the class and component counts are larger than the chat feature alone.
When this pattern fits — and when it doesn't
Build chat on Platform Events when Salesforce is already the system your team operates from, when messages need to participate in automation and reporting, and when your concurrency is clinical-scale — care teams and their patients, not anonymous consumer traffic. Stay with a vendor tool when messaging is genuinely standalone, when you need channels Salesforce does not natively speak from day one, or when nobody on your side will own custom code. This is real development: triggers, LWCs, a CometD integration, tests, and an error-logging discipline. The payoff is that the conversation and the care record finally live in the same place.
If you are weighing this against an AI-fronted service channel, our Salesforce AI chatbot architecture guide covers the grounding and handoff layer, and our behavioral-health build roundup shows the same event-driven playbook applied to EHR sync and AI intake. For the broader operating picture, see service and case operations, our Salesforce for healthcare page, and the Salesforce implementation service behind builds like this one.
Frequently asked questions
Can Salesforce really do real-time chat natively?
Yes. Platform Events deliver publish-subscribe messaging over the org's event bus, and Lightning Web Components can subscribe in the browser — via lightning/empApi inside Lightning Experience, or a CometD client in Experience Cloud sites. The system in this article has managed 100,000+ patient messages on exactly that architecture, with no middleware between the nurse and the patient.
Is patient messaging in Salesforce HIPAA compliant?
Compliance is a property of your program — your BAA with Salesforce, your policies, your training — not something a chat architecture can claim on its own. What the architecture controls is whether it becomes the weak link. We build HIPAA-conscious: PHI stays inside the org instead of transiting a third-party messaging vendor, access is governed by Salesforce sharing, and a companion audit trail logs who opened which patient record.
empApi or CometD — which one do I need?
Both, usually. lightning/empApi is the supported module for internal Lightning Experience components, but it is not available in Experience Cloud sites — so the patient-facing component needs a CometD client loaded as a static resource, with session handling you own. Plan for that split from day one; it is the detail most Platform Events chat tutorials skip.
What about Platform Event limits?
Event publishing and concurrent-subscriber allocations are real constraints, and you should size against your edition's limits before committing. A patient-nurse chat is bursty but modest — tens of concurrent subscribers, not tens of thousands. If you are building for very high concurrency, model the allocation math first; this pattern fits clinical-scale messaging, not consumer-scale chat.
Should we replace our patient-messaging vendor with Salesforce?
Only if the CRM is already your operational system of record and the vendor tool is fragmenting the patient story. If your team lives in the vendor tool and Salesforce is an afterthought, fix that first. The build cost is real — this is custom development with triggers, LWCs, and tests — and it pays for itself when message history on the patient record changes how care decisions get made.
Bring us the conversation you're losing
GAT Solutions builds revenue-generating systems for healthcare, accounting, and SaaS companies — fast, flawlessly, and powered by AI.
If your patient or customer conversations live in a tool your CRM has never heard of, bring the workflow to a working session. We'll map the buy-vs-build decision against your org and show you the architecture before you spend a dollar.