How to use Change Source data in workflows and reports

[LMC-Alex]

I'm trying to figure out how I can use property "change source" information in workflows and/or reporting (see screenshot).

My use case:
We have a number of different ways of updating data: 
1. Manual
2. Workflow
3. Data import

Our manual data is more reliable than the data we set via workflows and imports.

I want to:
a) Prevent workflows from overwriting manual data, whilst allowing them to overwrite data set by workflows or imports.
b) View which source data came from at scale within Hubspot, without having to export property history and work with an excel.

Any ideas?

Thanks!

[IohranAraujo · Accepted solution]

Hi @LMC-Alex ! Great use case — and you're absolutely right to treat manually entered data as more reliable in many cases.

Here’s a breakdown of how you can handle this in HubSpot, given the current platform limitations:

a) Preventing workflows from overwriting manually entered data

Unfortunately, HubSpot Workflows don’t have direct access to “change source” as a condition. But here’s a workaround:

Workaround with Custom Flag Property:

1. Create a custom checkbox property, e.g., Manually Confirmed.

2. When a user updates a field manually (e.g., via the record UI), train them to check this box.

3. In your workflows, add a condition:

   • Only update the property IF Manually Confirmed is not checked.

4. Optionally, create a workflow that sets this flag automatically when certain trusted fields are updated manually (requires custom code or ops hub).

It's not automatic tracking of change source, but it gives control to preserve manual input.

b) Viewing change source data at scale (reporting)

Currently, the change source (like "Workflow", "User", "API", "Import") is only available in the Property History view and via Export — not natively in reporting or workflows.

Workaround options:

• Use Data Sync tools or Ops Hub Custom Code to track last update method:

  1. On each update (via import, workflow, or API), set a property like Last Updated By Source to “Import”, “Workflow”, etc.

  2. You can then report or segment on this field.

• For manual updates, train users to set the Manually Confirmed property (as above), or use a custom coded workflow action to detect updates from a user ID.

• Use Ops Hub's Custom Code Actions to check the source of updates via the property history (advanced use).

TL;DR

• HubSpot doesn’t currently support “change source” natively in reports or workflow conditions.

• But with custom flags + usage discipline + optional Ops Hub logic, you can simulate control over what data gets overwritten and track source context.

If that helps, feel free to mark this as the solution so others can find it more easily!

[IohranAraujo · Accepted solution]

Hi @LMC-Alex ! Great use case — and you're absolutely right to treat manually entered data as more reliable in many cases.

Here’s a breakdown of how you can handle this in HubSpot, given the current platform limitations:

a) Preventing workflows from overwriting manually entered data

Unfortunately, HubSpot Workflows don’t have direct access to “change source” as a condition. But here’s a workaround:

Workaround with Custom Flag Property:

1. Create a custom checkbox property, e.g., Manually Confirmed.

2. When a user updates a field manually (e.g., via the record UI), train them to check this box.

3. In your workflows, add a condition:

   • Only update the property IF Manually Confirmed is not checked.

4. Optionally, create a workflow that sets this flag automatically when certain trusted fields are updated manually (requires custom code or ops hub).

It's not automatic tracking of change source, but it gives control to preserve manual input.

b) Viewing change source data at scale (reporting)

Currently, the change source (like "Workflow", "User", "API", "Import") is only available in the Property History view and via Export — not natively in reporting or workflows.

Workaround options:

• Use Data Sync tools or Ops Hub Custom Code to track last update method:

  1. On each update (via import, workflow, or API), set a property like Last Updated By Source to “Import”, “Workflow”, etc.

  2. You can then report or segment on this field.

• For manual updates, train users to set the Manually Confirmed property (as above), or use a custom coded workflow action to detect updates from a user ID.

• Use Ops Hub's Custom Code Actions to check the source of updates via the property history (advanced use).

TL;DR

• HubSpot doesn’t currently support “change source” natively in reports or workflow conditions.

• But with custom flags + usage discipline + optional Ops Hub logic, you can simulate control over what data gets overwritten and track source context.

If that helps, feel free to mark this as the solution so others can find it more easily!

[LMC-Alex]

Hi Iohran,

Thanks so much for your in-depth reply.

Training reps to mark manually just isn't an option - we can't rely on them to be consistent with this and it adds to much admnin to their process. We'd need to automate this somehow in order to to be valuable.

I've been looking at how to do this with custom code with an ops hub pro workflow, but am struggling to find the right endpoint.

The HubSpot API can return detailed property history (including source, timestamp, sourceId, etc.) — but this only works reliably using the legacy v2 endpoints.

Unfortunately, these v2 endpoints don't seem to be available in HubSpot’s custom code actions (which only support the v3 CRM API), and the propertiesWithHistory flag in v3 is inconsistent — even when you can see the history in the UI, the API often returns nothing.

Do you have any ideas where I can find the right endpoints to use in these custom code workflows?

Thanks!

[IohranAraujo · Accepted solution]

Hey @LMC-Alex 

You're right: custom code actions in workflows only support the v3 CRM API, and unfortunately, the v3 endpoints don’t expose detailed property history reliably — even with propertiesWithHistory=true, it’s hit or miss depending on the property type.

The catch (as you mentioned) is that this endpoint isn’t directly accessible in custom code actions — you could try to:

1. Proxy the request via a backend service (Lambda, Cloud Function, etc.) and call it from within your workflow.

2. Or—if using Ops Hub Enterprise—use external data fetch to bring in that data as a step.

Right now, there’s no native v3 alternative that exposes the same depth of property history as v2. 

If HubSpot ever opens up full v2 access in custom code or enhances v3 to return full history consistently, that’ll change everything. Until then… yeah, it’s a bit of a workaround.

Also, since this limitation hits a pretty common use case (especially for teams that want to automate around data quality and attribution), I’d really recommend submitting this as an Idea in the HubSpot Community Ideas Forum.

The more visibility this gets, the better the chance we see:

• Either v2 endpoints opened up for custom code actions

• Or v3 finally exposing full, reliable property history like we see in the UI

[Levi]

Maybe the drill down 1 / 2 source propeties will help? @LMC-Alex 

The following table shows the Original Traffic Source or Latest Traffic Source values and the possible Traffic Source Drill-Down values included in each category:

Original or Latest Traffic Source	Original or Latest Traffic Source Drill-Down 1	Original or Latest Traffic Source Drill-Down 2
Organic search	Search term (if available)	Search engine site
Referrals	Referring website domain	Referring website URL
Organic social	Social media site	Campaign name retrieved from the URL's utm_campaign parameter
Email marketing	Campaign name retrieved from the URL's utm_campaign parameter	HubSpot email name
Paid search	Campaign name retrieved from the URL's utm_campaign parameter	Search term (if available)
Paid social	Social media site	Campaign name retrieved from the URL's utm_campaign parameter
Direct traffic	Entrance URL	N/A
Other campaigns	Campaign name retrieved from the URL's utm_campaign parameter	Source / Medium

[LMC-Alex]

Hi Levi,

Thanks for your suggestion. Unfortunately that's not going to help here as these fields don't show me who (or what) was the last person (or workflow/import) to update specific properties.