Kipu Salesforce data sync: how patient data moves between the two

How Kipu Salesforce data sync works

The sync runs through the Kipu API. Salesforce calls Kipu with Apex, and the data moves in two directions, each with its own trigger.

• Salesforce to Kipu: the admissions team clicks "Send to Kipu" on the lead or opportunity, and Salesforce creates the patient in Kipu.
• Kipu to Salesforce: a scheduled Apex batch asks Kipu for updates and writes them back to the patient in Salesforce.

Keeping the two directions apart matters. Admissions owns the record until the patient is sent. After that, Kipu is the source for clinical dates and program history.

Kipu API access and permissions

Before anything syncs, the Kipu side has to be ready. Two things trip up new builds.

• The API app needs write and create patient permissions, not read access only. Without them, the push fails.
• The vendor app has to be linked to every Kipu location you send patients to. A location that is not linked will not accept the patient.

API credentials are stored encrypted in Salesforce, not in code, and each system only gets the access the sync needs.

Field mapping between Kipu and Salesforce

We write the mapping down before we build: a diagram of the flow and a sheet with every field, its Salesforce source, its Kipu target and its format. Your team signs it off.

These are the fields that come up in Kipu Salesforce mapping work:

• Demographics: name, date of birth, address, race and ethnicity, pronouns.
• Contacts: emergency contacts and guardians.
• Insurance: carrier, insurance company name, member ID, primary subscriber details and payment method.
• Admission details: level of care, admitting location and program.
• Documents: the pre-admission assessment, sent to Kipu as a PDF on the assessment tab.

Salesforce to Kipu: the Send to Kipu push

Kipu to Salesforce: the scheduled pull

A scheduled batch class reads patient updates from Kipu and matches them to Salesforce records by ID. What comes back:

• Admit date, discharge date and discharge type.
• Program history: each level of care and stay.
• Insurance carrier updates.
• Record keys such as the Kipu Master ID and patient record key, stored on the patient and the opportunity.

Set the timezone on purpose. Kipu dates and Salesforce dates have to agree on the timezone, or admit dates land on the wrong day in reports.

Record IDs, re-admits and historical patients

The ID is the link that holds the sync together. Keep the Kipu IDs on the Salesforce record and use them for every match, not names.

• Re-admits: a Re-admit button starts a new stay on the existing patient, carrying the Kipu Master ID, instead of a new duplicate patient.
• Historical patients: past patients from Kipu are loaded into Salesforce with their IDs, so reports include them from the start.
• Patients that exist in one system only: a summary email lists the mismatches, so they get linked or created.

What can and cannot sync

The sync can only move what the Kipu API exposes and what your Kipu account is set up to hold. Check these with Kipu before the mapping is final:

• Chart tabs and forms: if a tab is missing in a pre-admission chart, it is a Kipu configuration question, and Kipu support has to guide it.
• Location-specific setup: programs and levels of care differ by location, so build the program list per Kipu account.
• Clinical notes and treatment details stay in Kipu. Salesforce gets the dates and outcomes admissions and marketing need.

Testing and go-live

Want the full picture of the integration, with screenshots? See our Kipu + Salesforce integration page, or book a free call and we will map your fields with you.