AdvancedMD and Salesforce Integration: What Syncs Each Way

A multi-state psychiatric practice was entering every patient by hand twice: once in Salesforce, where admissions and scheduling work, and once in AdvancedMD, where the chart lives. The two records drifted and staff checked both. We connected them so a patient entered once appears in the other system within seconds, appointments included, with guards that stop a duplicate chart before it exists. This page is the operating view of that build: what moves, in which direction, and what keeps one patient one chart. The engineering view, with the webhooks and Platform Events, is in our AdvancedMD architecture write-up.

What syncs between AdvancedMD and Salesforce?

The field map is configuration. Each pair (AdvancedMD field name on one side, Salesforce field on the other) is a Custom Metadata record, so when AdvancedMD adds a compatible field, an admin adds one record instead of waiting on a deployment. Patient data is encrypted throughout.

How are duplicate charts stopped?

Duplicates start in three places: intake creating a patient who already exists, a sync message matched to the wrong record, and the same message processed twice. The build closes each one, in this order.

1. A warning at entry. Salesforce duplicate rules on person accounts check each new patient against existing ones, on an exact phone match and on Salesforce's standard person account rule, and ask intake “Use one of these records?” before the save. A duplicate rule decides what happens when someone starts creating a duplicate record (Duplicate Rules, Salesforce Help, read 16 October 2026). Ours alert rather than block, so staff make the call; a shared household phone is one reason a match is not the same patient.
2. Matching by ID, never by name. When a patient goes to AdvancedMD, the Salesforce record ID goes with it as an additional MRN, and AdvancedMD's chart number and patient ID come back onto the Salesforce record. Every later message is matched on those IDs, so two patients with the same name and birth date stay two records.
3. Appointments keyed by visit ID. Before writing an appointment, the flow looks for an event with the same AdvancedMD visit ID. If it finds one it updates it; if not, it creates one. A message that arrives twice, or a later status change on the same visit, updates the same event.
4. Every failure logged and alerted. A send or update that fails writes an error log record tied to the patient, with the response that explains it, and we get an alert when something upstream breaks, so a gap shows up as a record with an owner instead of a mismatch found weeks later.

What happens to an appointment once it reaches Salesforce?

Each AdvancedMD visit becomes a Salesforce event on the patient's opportunity, so the people working admissions see the schedule where they already work. Around it, the build turns appointment changes into work: a no-show or a cancellation updates the opportunity and opens a follow-up task, the opportunity carries a flag while the patient has a future appointment, and the visit's office location is copied to the opportunity. The 107,626 appointments in the stat rows above arrived this way, without anyone keying a schedule into Salesforce.

What does AdvancedMD require before you can connect?

Access is the vendor's process and it sets the earliest start date. AdvancedMD's developer page says (AdvancedMD developer solutions, read 16 October 2026):

• Its FHIR APIs are read-only and support GET requests only.
• An app that needs to create or update records uses the proprietary Connect APIs, which replicate nearly all of the AdvancedMD interface.
• Developers sign a Certified API Developer Agreement that carries licensing and support fees; the page publishes no amounts.
• Full documentation and a sandbox follow the signed agreement.
• Production credentials, including a unique app name, follow a successful integration demo with AdvancedMD's interoperability team.

A Salesforce side that is ready before those credentials arrive waits for them, so start the agreement when the project starts.

What does a referral provider need before it syncs?

Referral providers live in Salesforce as business accounts and go to AdvancedMD with their NPI. The rule we designed for that send, built as a draft flow in the sandbox and not yet switched on: a provider has to sit under a parent account, or be the parent itself. A provider without one would be held back, and the record would get a sync error message that says “Business Account must have a Parent Account”, so the person who entered it sees what to fix instead of a failed sync in a log.

Where does an AI phone agent fit?

The practice's AI phone agent feeds the same path. A call answered after hours arrives in Salesforce as a lead staff can work, and from there the patient follows the same send and the same guards to AdvancedMD. How we connect a voice agent to Salesforce is in voice AI lead intake for Salesforce.

What should you decide before building an AdvancedMD integration?

The same decisions apply to any EHR. For the census that runs next to this kind of sync, see how to build a self-correcting daily census in Salesforce; for API capacity, see Salesforce API limits for EHR integrations.

Frequently asked questions