Property history identifies the write event for workflow changes, not the workflow

Developer Support APIs & Integrations
1

The ask, in one line: carry flowId alongside sourceId on a property-history entry whose sourceType is AUTOMATION_PLATFORM. Additive, non-breaking, read-only.

What the entry says today. A workflow-sourced change carries sourceId: "enrollmentId:<id>;actionExecutionIndex:<n>". Checked against a live EU1 Enterprise portal across 28 history entries: every one of those ids appears on exactly one record. It identifies the write event, not the writer.

Compare the human case in the same sample. A CRM_UI entry carries sourceId: "userId:<id>", and one such id appeared across eight records. That id is an actor and it resolves.

So a person who changed a field is attributable through the API today, and a workflow is not.

And the enrolment id resolves nowhere. Checking every published OpenAPI spec, the only enrollment endpoints are sequence enrolments (/automation/v4/sequences/enrollments and its per-contact variant), which are a different object. /automation/v4 exposes flows, a batch read, email-campaigns, per-flow performance and workflow-id-mappings — nothing maps a workflow enrolment back to a flow.

Why this matters more each quarter. As Breeze and agent actions run inside workflows, “which automation set this value, and was a model involved” becomes a question customers ask about their own CRM. Property history is the natural place to answer it and is one field short of being able to.

A smaller second point. sourceLabel is documented as part of a history entry but was absent from all 28 entries we read — not empty, not present as a key. Either populating it or correcting the documentation would save integrators the round trip we spent.

Happy to talk this through: we build read-only audit tooling on HubSpot, and this is the one field between a useful governance signal and a reconstruction we have chosen not to ship because it would overclaim.

3

Hi @birdman ! This is exactly the kind of specific, well-evidenced feedback that’s most useful to the team building the CRM Property History and Automation APIs.

To get this in front of the right people, please submit it through the Developer Feedback form. To make sure it lands with full context, I’d suggest including:

  • Current behavior: AUTOMATION_PLATFORM history entries carry sourceId: "enrollmentId:<id>;actionExecutionIndex:<n>", which identifies the write event but doesn’t resolve to a flow through any published /automation/v4 endpoint (flows, batch read, email-campaigns, per-flow performance, workflow-id-mappings only).
  • Comparison case: CRM_UI entries carry userId:<id>, which does resolve and is attributable — showing the asymmetry between human- and automation-sourced changes.
  • Requested change: Add flowId alongside sourceId on AUTOMATION_PLATFORM entries — additive, non-breaking, read-only.
  • Secondary issue: sourceLabel is documented as part of a history entry but was absent (not null, not present as a key) across your 28-entry sample on a live EU1 Enterprise portal — worth flagging as either a bug or a doc correction.
  • Use case/impact: Read-only audit/governance tooling; growing relevance as Breeze/agent actions run inside workflows and customers ask “which automation set this value.”

Concrete before/after examples and reproduction details (like you’ve laid out) significantly help the product team prioritize and validate requests like this.

I hope this helps!

Cassie, Community Manager

4

Thanks Cassie. Already done, the same day: I submitted it through the Developer Feedback form on 31 August with the follow-up opt-in ticked, and it covers the five points you list, including the CRM_UI comparison and the sourceLabel absence. Flagging it here so nobody waits on me to send it.

One thing has been added to the case since. In the v4-sunset thread /automation/v4/flows/performance has no dated successor ahead of the v4 sunset a suggested workaround was to use property history with AUTOMATION_PLATFORM plus the flow id. That is this same missing field: someone who knows the API well reached for it as the obvious route, and it is not there. Worth adding if the submission reaches the team.

5

Thank you for flagging @birdman!

I will make sure the team hears the feedback :slight_smile:

Cassie, Community Manager

6

Cassie, one follow-up, and a question you may be able to answer more easily than I can find out.

The question first. I was told an app partner with a published Marketplace listing has developer support access from the developer account that owns the listing. I tried it today: the Help Center on our developer account offers community and a live chat, the live chat routed me to Sales, and Sales said ticket submission requires a paid account. Is there a support route for an app partner without a paid hub, or is the community the intended channel for API questions? Either answer is fine – I would just like to stop looking.

The follow-up. The property-history ask you offered to pass on has since merged with a second issue, and the pair is a sharper statement than either half. /automation/v4/flows/performance/{flowId} is the only public read of per-flow enrolment volume, and it has no dated successor ahead of the v4 sunset on 30 March 2027 – the 2026-09-beta namespace publishes every sibling path but not that one. Put together with the history finding:

after 30 March 2027 there is no public API surface connecting workflow activity to a workflow at all. Not which workflow wrote a value, and not whether a given workflow runs.

That is a capability the platform has today and would lose, arriving exactly as agent and Breeze actions start running inside workflows. And it has two independent fixes, either of which closes it: a dated flows/performance, or flowId carried alongside sourceId on an AUTOMATION_PLATFORM history entry.

If the version you are passing on is still the history ask alone, this is worth adding – it is the same team’s surface and it makes the case without needing the roadmap answer first. Thread with the detail: /automation/v4/flows/performance has no dated successor ahead of the v4 sunset