A national addiction-treatment network ran its entire admissions funnel in Salesforce — inquiry, verification of benefits, clinical screening, contract — and then, at the moment of admission, the process fell off a cliff: a coordinator re-keyed the patient into the Opus EHR from a paper packet. Demographics, insurance, emergency contacts, screening documents. Every admission, by hand.
This is the integration we built to replace that step, as it runs in production. The client is anonymized; the architecture and code figures come from our own audit of the build — a 989-line Queueable orchestrator, a 48-field screening object, and a funnel whose final stage change is the only trigger the EHR push needs.
The funnel that feeds it
Patients are Person Accounts; each admission is an Opportunity carrying 62 custom fields — demographics, insurance and VOB detail, program, therapists, admission and discharge dates, and the Opus linkage fields. The stages walk the real admissions process: VOB sent to billing, VOB received, screening complete, and finally the admitted stage that fires the push.
Two automations upstream make the final push complete. When a lead converts, a flow auto-creates the 48-field clinical screening with 31 fields pre-filled from the lead — the clinician reviews instead of re-typing, then files it as a branded PDF with one click. And when billing returns a verification-of-benefits document by email, an inbound email handler matches the Salesforce record ID embedded in the subject line and attaches the PDF to the right Opportunity automatically — original messages only, replies and forwards excluded.
The push: five endpoints, one Queueable
The admitted-stage flow makes one decision before enqueueing the job: does this patient already exist in Opus? It counts admissions on the account — first admission means create the patient; any later one means reuse the stored Opus patient ID and create only a new episode of care. Then the Queueable runs the sequence:
| Step | Opus endpoint | What it does |
|---|---|---|
| 1 | Auth | Obtains a bearer token — retrieved once, reused for every call in the transaction |
| 2 | Patients | Creates the patient from Person Account demographics (new patients only); Opus patient ID and MRN write back to Salesforce |
| 3 | Episodes of care | Creates the episode with program, admission dates, care team, consents, and referral context; episode ID writes back |
| 4 | Patient contacts | Creates the emergency contact when one is on file |
| 5 | Documents | Uploads every file on the Opportunity — screening, VOB, agreements — as multipart form data against the episode |
A typical new-patient admission with a full intake packet lands at roughly a dozen HTTP callouts across those five endpoint types. Every create validates its inputs and short-circuits its dependents; every failure logs status and body; and a standalone re-push action lets operations re-send documents to an existing episode without re-running the orchestration.
Configuration over code
Environment routing lives outside the codebase: connection settings in protected custom metadata, the endpoint behind a Named Credential, and the document host switching automatically between sandbox and production based on org context — the same deployment works in both without touching a line of Apex. An allow-list in custom metadata controls which document titles are eligible for upload, so the EHR receives clinical files, not every attachment that ever landed on the record.
Why this shape
This is the milestone push pattern: Salesforce owns the funnel, and the EHR record comes into existence at exactly the moment it should — admission — complete, duplicate-proof, and carrying its documents. When clinical staff instead live in the EMR all day and the CRM must mirror it continuously, you want the opposite topology: real-time event-driven sync, which we cover in Salesforce EMR integration for behavioral health alongside the decision framework for choosing between them. For the broader set of what we've shipped in this vertical, see the behavioral-health build library.
Frequently asked questions
Can Salesforce integrate with the Opus behavioral-health EHR?
Yes. Opus exposes REST endpoints for authentication, patients, episodes of care, patient contacts, and document upload. We run a production integration where an admitted Opportunity automatically creates the patient, the episode of care, the emergency contact, and every attached clinical PDF in Opus — no re-keying.
How do you prevent duplicate patients in Opus on repeat admissions?
Three layers. The trigger flow counts admissions on the patient's account: the first creates an Opus patient, later ones only create a new episode of care. The Opus patient ID and MRN write back onto the Salesforce record after the first push. And a before-save flow copies those IDs onto any new admission for the same patient, so linkage exists before the push ever fires.
How are clinical documents transferred to Opus?
At admission, the job queries every file attached to the Opportunity — the pre-admission screening PDF, verification-of-benefits documents, signed agreements — and uploads each to Opus's document endpoint as multipart form data against the episode of care. Because inbound VOB emails already file themselves onto the right Opportunity, the whole packet arrives in the EHR without anyone gathering attachments.
What happens if a callout fails mid-sequence?
Each step validates its inputs and short-circuits its dependents — no episode, no document upload. Every failure is logged with status and response body, and a standalone re-push action lets operations re-send documents to an existing episode without re-running the whole orchestration. Because every create is idempotent, re-running is safe by design.
Admissions team re-keying patients into Opus — or any behavioral-health EHR? Bring us the workflow. See what we build for healthcare operators.