Salesforce-to-HubSpot Integration for a Multi-Brand Aged Care Charity
An independent charitable aged-care and home-care provider ran several affiliated brands, through one shared HubSpot portal. But Salesforce held the consumer and lead data behind it, and submitted web form records needed to reach HubSpot. We built a relay through the client's own server and the HubSpot Forms API instead. A Salesforce confirmation decides whether HubSpot can market to the new contact, and Business Units, user permissions and Content Partitioning keep one brand's team from opening another's records inside the same portal.
Executive Summary
Context
The provider's marketing and admissions data sat in Salesforce, fed by Forms Assembly web forms. Several sibling brands, including a dementia-care arm, needed to operate inside one shared HubSpot portal. Submitted form records needed to reach HubSpot, and none of the brands could be allowed to see another's contacts once the data arrived.
What We Built
We built a relay from Forms Assembly through Salesforce to the client's own server, with a custom API layer against HubSpot's Forms API. The relay is gated on a Salesforce confirmation and a status-change suppression rule. We also layered HubSpot Business Units with user permissions and Content Partitioning across the sibling brands, so each brand's contacts stayed inside its own team's view.
Tech Stack
- HubSpot
- Salesforce
- Forms Assembly
- HubSpot Forms API
- HubSpot Business Units
- HubSpot user permissions
- Content Partitioning
Not a fit if you operate a single brand inside one HubSpot portal, since the user permissions and Content Partitioning here exist to keep separate brand teams apart, not to organise one team's own data. It's also not a fit without a server of your own to run as middleware, because the relay depends on a client-owned server sitting between the source CRM and the HubSpot Forms API.
The Challenge
Consumer and lead data for the provider's aged-care and home-care brands lived in Salesforce, fed by Forms Assembly web forms on the public site. No existing path pushed a submitted form into HubSpot, so the marketing team couldn't act on a new lead the moment it arrived. Someone had to move each record across by hand, or wait for a batch process. The problem grew as sibling brands, including a dementia-care arm and other affiliated brands, joined the same HubSpot portal, because HubSpot's marketing lists depended on data that only existed on the Salesforce side of a missing bridge.
Bringing those brands onto one shared portal also created a second problem. HubSpot Business Units group brands together but don't, on their own, stop one brand's team from opening another brand's contact records.
With aged care, home care, a dementia-care arm and other affiliated brands all in one contact database, a support rep on one brand could see, and potentially edit or message, a lead belonging to another brand. A shared charitable network couldn't accept that exposure.
Our Approach
We designed a relay. A submission posts into Salesforce, and a process on the client's own server, acting as middleware, picks it up and posts it on to HubSpot through a custom API layer built against the HubSpot Forms API. The relay keys on Contact Name, Email and the Brand or Division field.
Two gates control what happens next. HubSpot adds a contact to the correct Division's marketing list only after Salesforce confirms it created the record. A second gate watches for a status change, such as a contact becoming a customer or opting out, and removes or re-routes that contact out of marketing communications.
On top of the relay, Business Units, user permissions and Content Partitioning scope View, Edit, Delete and Communicate access on every contact to Everything, Team Only, Owned Only or None. That scoping follows the owner and team that a workflow assigns, from the Brand or Division property, when a record is created. It trades one flat contact database for four separate views of it, which is the logical partitioning the portal needed once Business Units alone proved insufficient.
Impact
New leads reach marketing the moment Salesforce confirms them
A Forms Assembly submission now flows through Salesforce and the client's own server to the HubSpot Forms API without anyone moving the record by hand. A new lead reaches the correct Division's marketing list once Salesforce confirms the contact exists. A second gate watches for a status change, so a contact who becomes a customer or opts out is removed or re-routed automatically.
One brand's team can no longer open another brand's contacts
Every contact now carries a Brand or Division property set when the record is created, and View, Edit, Delete and Communicate access is scoped to Everything, Team Only, Owned Only or None for each user and role. That closed the exposure Business Units alone left open. A support rep on one sibling brand can no longer see, edit or message a lead that belongs to a different brand on the same portal.
The relay carries form submissions into HubSpot
The client's own server sits in the middle of that handoff as middleware, translating a Salesforce record into a HubSpot Forms API call as soon as it appears.
Every sibling brand runs on the same isolation rules
The Division property, the two-gate suppression logic and the user permissions apply the same way across every brand on the shared portal, so a brand added later inherits the same partitioning instead of needing a one-off build. That consistency let the aged-care, home-care, dementia-care and other brand teams share one HubSpot instance without one team's send list including another's contacts.
A consumer's Forms Assembly submission posts into Salesforce first. A process on the client's own server watches for new records and posts each one on to HubSpot through a custom API layer built against the HubSpot Forms API. The relay keys on Contact Name, Email and the Brand or Division field, so nobody needs to re-enter a submission by hand.
The first gate holds a new contact out of any Division's marketing list until Salesforce confirms the record exists, so HubSpot never sends to a lead that Salesforce hasn't yet accepted. The second gate watches for a status change and removes or re-routes the contact out of marketing communications on that same signal.
A HubSpot workflow sets the Brand or Division property as soon as a contact record is created, and ties it to a Contact Owner and a Team. Every downstream permission and marketing-list decision reads from this one property, so the relay and the access rules stay in sync.
HubSpot Business Units group the sibling brands, but View, Edit, Delete and Communicate access on each contact still had to be scoped separately to Everything, Team Only, Owned Only or None. User permissions and Content Partitioning carry that partitioning, and they close the gap Business Units leave open between brands sharing one portal.
Forms Assembly submissions needed to reach HubSpot from Salesforce. Sharing one portal also meant a rep on one brand could open another brand's contacts. Now a relay on the client's own server posts each submission to the HubSpot Forms API. A contact joins its Division's marketing list only after Salesforce confirms the record. User permissions then scope View, Edit, Delete and Communicate access on every contact, following the owner and team set from the "Brand or Division" property.
FAQ
A Forms Assembly submission posts into Salesforce, and a process on the client's own server picks it up and posts it to HubSpot through a custom API layer built against the HubSpot Forms API. The relay keys on Contact Name, Email and the Brand or Division field.
HubSpot Business Units organise the sibling brands but don't restrict who can open a record. So we layered user permissions and Content Partitioning on top, scoping View, Edit, Delete and Communicate access on every contact to Everything, Team Only, Owned Only or None. That scoping follows the owner and team that a workflow assigns, from the Brand or Division property, when a contact record is created.
