HubSpot behaviours that report success and do nothing
Systems that fail loudly get fixed. These are the ones that return 200, render correctly, and quietly do nothing — collected from live portals, with the pattern that does work and the check that proves it.
- What this is
- Twelve HubSpot behaviours where an operation is accepted and never takes effect. Each entry gives the symptom you see, what is actually happening, the pattern that works, and how to verify it.
- Who it is for
- Anyone who has looked at a HubSpot workflow that is enabled, correctly configured by inspection, and has plainly never done anything — and could not work out why.
Free, no email required, no sign-up. Anything you type into a tool on this page stays in your browser and is never sent anywhere. The visit itself is counted by Google Analytics, as on every page of this site.
Why this list exists
A failure that throws an error gets fixed the same day. A failure that reports success can run for years. Every entry below was found on a live portal where something had been quietly not working, in most cases for long enough that the business had built process around the gap.
None of these are documented as failure modes. Several are not documented at all — the accepted formats for built-in workflow action fields, for instance, appear in no public specification, and were established by building the thing in the interface and reading it back through the API.
The general defence is the same in every case: verify at the far end. Read the record, read the filter back, read the action log. Never trust the response at the near end, because the response is the thing that is lying.
1. Association absence expressed with NOT_IN_LIST
Symptom: a workflow is enabled, its criteria read correctly, and it has never enrolled a single record. Workflow history is empty rather than erroring.
What actually happens: association absence cannot be expressed with NOT_IN_LIST. The Lists API rejects the filter outright. The Workflows API accepts the identical filter, stores it, and leaves it permanently inert. There is no error, no warning in the interface, and nothing in history to distinguish it from a workflow waiting for its first match.
The working pattern: a LIST_BRANCH on IN_LIST, with the action on the DEFAULT path. You are expressing "is in the list" and acting on everything that falls through, rather than trying to express "is not in the list".
How to verify: build two throwaway lists for the positive and negative cases and compare their counts against the total. On one portal that showed 453 of 662 deposit deals carried the association — which is what proved the rebuilt version was matching the right records.
2. A latch property cannot stop concurrent enrolment
Symptom: an internal notification arrives several times for the same account. Adding a marker property to stop it appears to work, then it happens again.
What actually happens: a latch assumes records are evaluated in sequence — first one through stamps the marker, the rest are excluded by it. HubSpot evaluates many records in the same window, so every one of them reads the marker as unset before any has written it. On a live account with three contacts, all three passed and all three sent.
The working pattern: change the object the workflow enrols so it matches the object the condition describes. If the truth lives on the company, enrol the company. This makes the duplication structurally impossible rather than merely unlikely.
How to verify: after enabling, count records still eligible. It should be zero. Then confirm enrolments equal the number of deliberate test records and nothing more.
3. Recurring tasks inherit the original subject
Symptom: a report meant to measure work a person did includes work a machine generated, and the numbers are inexplicably high.
What actually happens: tasks arrive from three sources — created by a person, generated by a workflow, and produced by a recurring repeat. Recurring repeats inherit the subject line of the original human task, so the same task reads as human the first time and as machinery every time after, while looking identical.
The working pattern: filter on the record's own source field. Any rule based on something human-readable will misattribute machine work to people, silently.
How to verify: the source field is not exposed in the report builder, so confirm the definition against a hand-built count before anyone's review depends on it. On one portal that comparison came out at 236 against a hand-built 240 — close enough to confirm and different enough to explain.
4. Multi-select report filters drop values on save
Symptom: a report returns fewer records than expected, and the filter looks right when you glance at it.
What actually happens: multi-select filter values can be silently discarded on save. The write is accepted and the stored filter carries fewer values than you set.
The working pattern: there is no way to prevent it. Read the filter back after writing it and compare against what you intended.
How to verify: read-after-write, every time, on any report filter that carries more than one value.
5. Form submissions accepted and discarded as spam
Symptom: an integration posts submissions, receives a success response, and no contacts appear. Nothing is queued, nothing errors, no rate limit is hit.
What actually happens: a submission carrying a page reference on a domain the portal does not recognise is treated as spam and discarded — while still returning a success response.
The working pattern: send no page-context block at all from a server-side integration, or register the domain. The context block is what triggers the rejection.
How to verify: end to end on a real payload, by reading the created record. A first theory about rate limiting was wrong here, and only reading the far end settled it.
6. Extra team members are excluded from rotation
Symptom: someone added to a team as an additional member never receives a rotated lead.
What actually happens: rotation actions consider primary team membership. Additional members are excluded by design, which is documented but easy to miss when the interface shows them on the team.
The working pattern: adjust primary team membership, or edit the rotate action itself to include the user. Adding someone as an extra member is not a workaround.
How to verify: read the rotate action back and confirm which identifiers it carries — team or individual.
7. Date filters reject every obvious format
Symptom: a date filter written through the API is rejected, whichever format you try.
What actually happens: epoch milliseconds, a year/month/day array and an ISO string are all rejected. The API wants a structured time-point object carrying timezone source, zone, the date parts, an endpoint behaviour and a parser.
The working pattern: build the filter once in the interface, read it back through the API, and use that shape as your template. The structure is not discoverable any other way.
How to verify: read back after writing, as with every filter.
8. Workflow data sources are stripped on write
Symptom: a workflow deployed through the API loses the personalisation token it was given, and a subsequent update reports success while the read-back shows the field empty.
What actually happens: the v4 flow API silently strips data sources on deploy, update and clone. One update returned a verified response naming the field as changed while the read-back showed it empty.
The working pattern: deploy through the API ignoring data sources, insert the token through the interface picker — which is what actually creates the data source — save, read the flow back, then set the final value through the action-level update, which does preserve it.
How to verify: read the flow back and inspect the field directly. The success response is not evidence here.
9. Property listing truncates without saying so
Symptom: you conclude a property does not exist, and it does.
What actually happens: listing contact properties truncates at roughly 375 entries with no error and no pagination signal.
The working pattern: query the specific property directly rather than scanning a list.
How to verify: before concluding any property is absent, look for one you know exists. If that is missing too, you are being truncated.
10. Engagement listing ignores its object filter
Symptom: a query for activity on one record returns unrelated records.
What actually happens: the engagement listing endpoint ignores the object identifier it is given and returns a broader set.
The working pattern: filter the results yourself, or use a search endpoint that honours the constraint.
How to verify: check that every returned record is actually associated with the object you asked about. Do not assume the filter applied.
11. A derived flag is only as true as its input
Symptom: a paying customer reads as having no active agreement, and the flag looks correctly maintained.
What actually happens: the flag is derived by a maintenance workflow from a date on the company record. When that date fails to arrive, the flag is correctly reporting a blank input — and renewals, churn reporting and the at-risk register all read the flag.
The working pattern: never set a derived flag by hand. If it reads wrong on a live customer, fix the input behind it; writing the flag directly masks the fault while appearing to resolve it.
How to verify: trace backwards from the report to the field to the source record, and confirm the derivation runs by watching it flip after you correct the input.
12. The same property name on two objects
Symptom: a write succeeds and the value does not appear where you expected it.
What actually happens: the same internal property name can exist on more than one object — a deal and a company, for instance. Writing to the wrong one is accepted without complaint.
The working pattern: be explicit about the object on every call, and confirm which one a property belongs to before writing to it.
How to verify: read the record you meant to change, not the response you received.
What this will not tell you
- This is not a HubSpot audit checklist. There are already ten good ones; this is the list of things a checklist will pass.
- Everything here was observed on live portals between 2026 and now. HubSpot ships changes constantly — verify against your own portal before acting on any of it.
- Several entries describe undocumented behaviour. Undocumented means it can change without notice, not that it is guaranteed.
Every entry was found during live client work, recorded at the time with the evidence that established it. No client, portal or record identifier appears anywhere on this page.
Questions people ask about this
Why would a HubSpot workflow be enabled and enrol nobody?
The most common cause is an enrolment filter that the Workflows API accepts and stores but can never match — association absence written as NOT_IN_LIST is the classic case. The Lists API rejects that filter outright; the Workflows API saves it and leaves it permanently inert. Nothing errors, workflow history shows no failures, and the workflow is indistinguishable from one waiting for its first match.
How do I tell whether a HubSpot workflow has ever actually run?
Read the action log rather than the configuration. Configuration tells you what the workflow could do; only the log records what it did. A workflow can be enabled, correct by inspection, and have enrolled nobody for years — and no configuration audit will catch it.
Does HubSpot have a scheduled or cron workflow trigger?
Yes, but the recurrence is subscription-gated. The Based on a schedule enrolment trigger will run a workflow at a set date and time, and recurring daily, weekly, monthly or annual frequencies require a Data Hub Professional or Enterprise subscription. On a portal without it the frequency options are not shown at all, and a recurring task is the practical substitute — worth describing to a client as a task rather than as automation.
How do I separate human-created CRM tasks from workflow-generated ones?
Filter on the record's own source field. Subject lines do not work: recurring task repeats inherit the subject of the original human task, so the same task reads as human the first time and as machinery every time after. Note that the source field is not exposed in the report builder, so reports need it applied a different way.
Why did my HubSpot report filter lose its values after saving?
Multi-select report filters can silently drop values on save. The write is accepted and the filter comes back with fewer values than you set. The only reliable check is to read the filter back after writing it and compare against what you intended.
If something in your portal is enabled and plainly not working, this is the class of cause worth checking first — and it is most of what a configuration audit will pass over.
HubSpot Engineering