Healthcare Success Story
How JumpstartMD Achieved Personalized Patient Communications Through a Rescoped Salesforce Data Model
JumpstartMD is a health and wellness company running its patient, membership, and appointment data through Salesforce. Campaign Creators audited Salesforce's custom-object model, scoped it to fit HubSpot's native sync limit, and split a combined date-and-time field so appointment reminders could be personalized and automated.
.png?width=1200&height=800&name=CC%20Blog%20Images%20(65).png)
0
Patient appointment records synced from Salesforce into HubSpot
0
Patient accounts unified into a single CRM view
0
Sales opportunities consolidated into that same view
0
Salesforce custom objects scoped to fit HubSpot's native 10-object sync limit
JumpstartMD is a physician-led weight-management and wellness practice operating 14 clinic locations across California with a team of 250. Salesforce holds its patient, membership, and appointment data as the system of record, feeding the marketing and communications work that runs in HubSpot.
Two systems holding two halves of one patient relationship puts a requirement on the connection between them. Appointment details sit in Salesforce, the messages that reference those details send from HubSpot, and a patient scheduled at one of fourteen clinics needs their own date, time, and location in the reminder they receive. What the integration can carry therefore sets the ceiling on how personal those messages can be.
Industry
Health & Wellness
Tools Used
- HubSpot Marketing Hub Enterprise
- Salesforce CRM
Services
- Salesforce Data Architecture
- CRM Integration
The Challenge
JumpstartMD's patient, membership, and appointment data lived in Salesforce, and the marketing team needed that data to drive patient-facing messaging in HubSpot. The native integration between the two systems could not carry it in the form the messaging required. Salesforce's data model exceeded what HubSpot's native sync accepts, the fields that mattered sat on the wrong object for HubSpot workflows to reach, and the single most important field was stored in a format no HubSpot message could read.
Until those constraints were resolved, appointment reminders could only be generic. A patient scheduled at one of fourteen clinic locations received the same message as a patient scheduled at any other, on any other date, at any other time.
.png?width=1080&height=1080&name=Hero%20Image%20Templates%20(28).png)
What Stood Between Salesforce Data and a Personalized Message
1. A Salesforce model larger than the sync could take.
JumpstartMD's full data model called for 16 custom objects, more than the 10 HubSpot's native integration can sync. Attempting a full replica would have hit that ceiling partway through, with no control over which objects made it across.
2. Appointment data on the wrong object.
Appointment and transaction records lived on the Salesforce Account object, but HubSpot workflows trigger from a Contact. The data was present in HubSpot and unreachable by the workflows that needed it.
3. A combined date-and-time field.
Salesforce stored each appointment's date and time as a single field. HubSpot personalization tokens could not read it, which meant the one detail every reminder depends on was unusable in a message.
4. Workflows built on properties that were about to change.
The existing messaging workflows referenced the old property structure. Restructuring the underlying data meant every dependent workflow and template had to be rebuilt to match, not simply repointed.
5. A record volume that ruled out a single-pass migration.
Salesforce held hundreds of thousands of records across objects with dependencies between them. Moving them without a defined order risked landing patient and appointment data in a structure still being defined.
6. No margin for error at go-live.
Appointment reminders reach patients about scheduled care. A workflow-criteria error would surface as a patient receiving the wrong time, the wrong location, or no reminder at all.
“JumpstartMD's Salesforce instance held more custom objects than HubSpot's native integration could take at face value, so we made a call to audit the model first and scope down to what actually powered patient communication, not attempt a full sync that would have hit the limit halfway through.”
Kiara Carniewski, Account Executive, Campaign Creators
Why JumpstartMD Chose Campaign Creators
JumpstartMD needed a partner who could work inside HubSpot's native integration limits without leaving critical patient data behind in Salesforce, and who had the technical depth to solve a data-formatting problem native HubSpot properties could not handle on their own. The engagement called for:
- Auditing a Salesforce instance with as many as 16 custom objects to identify which mattered most to patient communication
- Re-associating appointment and transaction data from the Salesforce Account object to the Contact object HubSpot workflows require
- Splitting a combined date-and-time field into properties usable in dynamic personalization tokens
- Rebuilding the workflows and message templates that depended on that data once the underlying properties changed
How Campaign Creators Rescoped JumpstartMD's Salesforce Data Model for Personalization
Campaign Creators scoped the data model before touching messaging: first auditing which Salesforce custom objects actually mattered, then rebuilding the property structure and workflows those objects fed. No messaging work started until the underlying data could support it.
Scoping 16 Salesforce Objects Down to 10
JumpstartMD's full Salesforce data model called for 16 custom objects, more than the 10 HubSpot's native integration can sync. Campaign Creators ran a dedicated CRM Strategy and Data Modeling audit and narrowed that list, including the Appointments object at its core, to fit inside HubSpot's native 10-object cap. JumpstartMD's HubSpot instance runs on that scoped model, not an attempted full replica of Salesforce, so it can absorb new use cases without hitting the 10-object ceiling again.
Mapping Standard Salesforce Objects Into HubSpot
Salesforce's standard objects do not automatically carry the field-level detail HubSpot needs to trigger personalized messaging. Campaign Creators mapped Salesforce's standard objects, Contacts, Leads, Accounts, Opportunities, Cases (one-way), and Tasks, through HubSpot's native Salesforce integration, alongside the scoped custom objects. JumpstartMD's marketing team can now build messaging logic directly against real Salesforce fields, without routing each change through a developer.
Syncing Standard Objects Before Custom Ones
JumpstartMD's Salesforce database held hundreds of thousands of records across objects that could not simply be dropped into HubSpot without a migration order. Campaign Creators migrated JumpstartMD's full scope of appointment, account, and opportunity records from Salesforce into HubSpot, sequencing the newly scoped custom objects to sync only after the standard-object foundation was in place. Patient and appointment data landed inside a data model already built to support it, not into a structure still being defined.
Splitting Date and Time Into Usable Properties
Salesforce stored each appointment's date and time as a single combined field, a format no HubSpot message could read for personalization. Campaign Creators created separate Date and Time properties on the Contact and Appointment records, then defined a set of dynamic personalization tokens covering a patient's name, appointment date and time, and clinic location detail (name, street, city, state, zip, directions, door code, phone, and email). Every property in that set was defined by what a patient-facing message actually needed, not by what Salesforce happened to already track.
Moving Appointment Data Onto the Contact Record
Appointment and transaction records lived on the Salesforce Account object, but HubSpot workflows only trigger from a Contact. Campaign Creators re-associated that data to the Contact record before it reached the workflows that generate reminder messages. This engagement's scope covered that Contact-level re-association specifically; it did not include building role-based record views for different JumpstartMD user types, which remains outside what was delivered here.
Rebuilding 9 Workflows on the New Properties
None of the newly synced or restructured data could reach a patient until the messaging workflows themselves were rebuilt to use it. Campaign Creators rebuilt 9 workflows around the new Date and Time properties, including:
- Appointment reminder SMS, triggered ahead of each patient's scheduled appointment, sent to the patient contact with personalized date, time, and clinic location
- Appointment reminder email, triggered on the same schedule, sent to the patient contact with the same personalized details
Testing Reminders Against Real Appointment Records
A rebuilt data model and workflow set could not go live without confirming the new criteria actually behaved as intended across real appointment data. Campaign Creators ran a final system review ahead of go-live, testing the rebuilt reminder workflows against real appointment records and correcting workflow-criteria issues before launch, so personalized messaging reached patients correctly from the first send.
The Results
Once the data model and workflows were rebuilt, JumpstartMD's appointment communications shifted from manual and generic to automated and personalized. Key outcomes included:
- Salesforce appointment, account, and opportunity data became usable for personalized, automated messaging once synced into HubSpot's contact and appointment properties
- Salesforce's custom-object model, once scoped to fit HubSpot's native 10-object limit, no longer blocks new patient-communication use cases from syncing
- Appointment date and time, previously combined in a single Salesforce field, now populate as two separate properties usable inside HubSpot messages
- Appointment reminder messages, by SMS and email, send automatically to each patient contact ahead of their scheduled appointment, using that patient's own appointment date, time, and location, replacing generic reminder text
Every one of those sends now draws on JumpstartMD's own Salesforce data, resolved into a format HubSpot can use natively.
.png?width=1080&height=1080&name=Hero%20Image%20Templates%20(29).png)
The Impact: A Data Model Built to Extend, Not Rebuild Again
The custom objects Campaign Creators prioritized, layered on top of JumpstartMD's standard Salesforce sync, cover the data that actually powers patient communication, with the Appointments object at its center. That object list came from a dedicated audit, not an attempt to replicate everything Salesforce holds, so JumpstartMD's HubSpot instance can absorb new personalization use cases without exceeding its native 10-object sync limit again. The same approach used to split Salesforce's combined date-and-time field into two properties, and to re-associate appointment data to the Contact record, is available to apply to any future record type that needs to trigger a HubSpot workflow.
Solve Salesforce Integration and Data Architecture Gaps With Campaign Creators
Businesses running Salesforce as their system of record and HubSpot for marketing hit the same wall eventually. The data that would make communications personal lives on the wrong object, in the wrong format, or beyond what the native integration can carry. Closing that gap starts with the data model, not the messaging, because a message can only be as specific as the properties behind it.
Campaign Creators is a HubSpot Elite Solutions Partner building the foundation underneath that work: Salesforce data architecture, CRM integration, property and object modeling, and the automation that runs on top once the structure holds. We scope what the platform can actually support, restructure what it cannot, and document the result so your team extends it without routing every change through a developer.
Get HubSpot and Salesforce Working as One System
Campaign Creators builds the layer between your system of record and the platform your team markets from: Salesforce data architecture, bidirectional CRM integration, object and property modeling, and the workflows that run once the structure holds. We build it to be owned in-house, documented and extendable, so the next use case doesn't mean another engagement.