Skip to content
Solutions Blueprint

HubSpot Lead Source Property Governance for a Commercial Design Firm

Hero featured image

A commercial design firm's HubSpot portal took most of its contacts from a continuous Salesforce sync, and its Lead Source property had grown to more than 440 dropdown values referenced across 151 workflows. We scoped a fix to the trigger that mattered: a workflow for every Salesforce-sourced contact, plus a company-to-contact association setting the first audit had found disabled.

Executive Summary

context-header-icon

Context

A commercial interior design and workplace-strategy firm ran its HubSpot portal on contacts synced continuously from Salesforce, its CRM of record. By its second portal audit, the firm's Lead Source property carried more than 440 values.

what-we-built-header-icon

What We Built

We built a Lead Source workflow that sets the property to Salesforce for every Salesforce-sourced contact, and closed a company-to-contact association gap the first audit had flagged as disabled.

tech-stack-header-icon

Tech Stack

  • Salesforce
  • HubSpot Marketing Hub Enterprise
  • HubSpot CMS Hub Enterprise

Not a fit if most of your contacts don't arrive through an external CRM sync carrying its own source-of-record signal, since the fix depends on a reliable Original Source and Drill-Down combination to trigger on.

the-challenge-header-icon

The Challenge

Contacts that came into the firm's HubSpot portal from Salesforce carried an Original Source of Offline and a Drill-Down value of SALESFORCE. Each one wrote to a Lead Source property that was meant to record where the contact came from. By the first portal audit that dropdown had more than 440 values, and 28 workflows referenced it.

Fourteen months later the property appeared in 151 workflows, more than five times as many, while the contact count climbed from 210,000+ to 240,000+.

And because so many workflows depended on the property, the firm couldn't prune it without breaking whatever those workflows checked it for.

our-approach-header-icon

Our Approach

The obvious first move was to trim the dropdown to a shorter list. But 151 workflows were already keyed to specific values, and none of them had been re-audited, so removing options risked breaking their logic. We left the existing values alone.

Instead we scoped the fix to the trigger that mattered: a contact created through the Salesforce integration, identified by an Original Source of Offline and a Drill-Down value of SALESFORCE. For that trigger we built a workflow that sets Lead Source to Salesforce, so every Salesforce-sourced contact carries the same source value.

We also closed the company-to-contact association gap that the first audit had flagged as disabled, because an unassociated company left every contact under it invisible to account-level reporting. The trade-off is that we governed one property against one trigger instead of cleaning up the list.

impact-header-icon

Impact

check-icon

Offline-sourced contacts stop competing for Lead Source credit

Every contact created through the Salesforce integration now has Lead Source set to Salesforce by the workflow, so the property stops splitting attribution credit for records that already have a system of record. The 151 workflows referencing Lead Source keep working, because the fix governs which value a record gets rather than removing an option they depend on.

check-icon

A precise trigger for Salesforce-sourced contacts

The workflow keys on an Original Source of Offline and a Drill-Down value of SALESFORCE, so HubSpot-native form submissions are left untouched.

check-icon

Contacts became visible to account-level reporting again

Automatic company-to-contact association, flagged as disabled at the first audit, was enabled by the second, so contacts synced from Salesforce started rolling up under their company record instead of sitting unassociated. Reporting grouped by account could count records it had been missing.

check-icon

Existing workflows keep their Lead Source values

The existing Lead Source values were left in place, so no workflow failed because a value it checked for had been deleted. Governing the trigger instead of the value list kept the property's existing values intact.

Technical Blueprint
1

A contact created through the Salesforce integration carries an Original Source of Offline and a Drill-Down value of SALESFORCE, the two properties the workflow checks before touching Lead Source. Scoping the fix to this trigger left HubSpot-native form submissions untouched.

2

The workflow sets Lead Source to Salesforce for every matching contact.

3

Lead Source stayed a single dropdown carrying more than 440 values and referenced by 151 workflows, none removed or renamed by this fix. Governing the trigger that populates one value left every other workflow keyed to the property's existing values working as it had before.

4

Automatic company-to-contact association, the setting linking a contact record to its company without manual intervention, had been left disabled at the first audit. Enabling it meant Salesforce-synced contacts rolled up under the correct company instead of arriving as an orphaned record.

Salesforce-created contacts get Lead Source set by a workflow.

The "Lead Source" property had more than 440 values, and 151 workflows referenced it. Trimming the list risked breaking whatever those workflows checked, so we left the values alone. Now a workflow sets "Lead Source" to Salesforce only if the contact came in through the Salesforce integration, with an Original Source of Offline and a Drill-Down value of SALESFORCE. That gives every Salesforce-sourced contact the same source value.

FAQ

Why not just delete the low-use values in the Lead Source dropdown?

Because 151 workflows already referenced the property, and removing a value could break any workflow that checked for it. Governing which value a new Salesforce-sourced contact gets, rather than editing the list, fixed the attribution problem without touching workflows that depended on values already in place.

Does a workflow like this work for any Salesforce-synced HubSpot portal?

It works where the property already has a defined source-of-record trigger you can check, such as an Original Source and Drill-Down combination. If your portal can't distinguish a Salesforce-sourced contact from a native one, you would need to build that identification first.

footerCTA footerCTA-mobile
Spice up your inbox
Sign up for our newsletter
Don't worry - we only average, like, two emojis per subject line.