PSA: the Workflows API accepts an association-absence filter that silently never runs

Sharing something that cost me a while to find, in case it saves someone else the same afternoon.

Association absence cannot be expressed with a NOT_IN_LIST filter but only one of the two APIs tells you that.

The Lists API rejects the condition outright. You get a clear error, and you go and build it a different way.

The Workflows API accepts the identical filter, stores it, and leaves it permanently inert.

There is no error on save. Nothing in the workflow’s history. Nothing in the builder to distinguish it from a workflow that is simply waiting for a record to match, it renders back correctly, because the builder renders what was stored, and what was stored is syntactically valid and semantically dead.

I found three of these in one portal. All enabled, all sensible-looking in the UI, none had ever enrolled a single record.

How to check whether you have one

Don’t read the configuration. Open the workflow’s history, set the widest date range available rather than the default last seven days, and read total enrolments since it was enabled. Separately, count the records you believe should have matched. Zero enrolments against a non-zero population is your sign.

What work

Invert the logic into a form both APIs evaluate:

  1. Build an active list of records that do have the association, using IN_LIST. That form is accepted and evaluated correctly.
  2. In the workflow, add a list branch on membership of that list.
  3. Put the action on the DEFAULT path, non-members are the records missing the association.

Two things before you enable it. Verify the branch semantics against real data first: I used two throwaway lists and found 453 of 662 deals had the association, so the default path should produce 209, which it did. And date-bound the enrolment trigger, because switching on a workflow that’s been dead for two years will otherwise notify your team about every historical record the moment it starts working.

If you build this in the UI instead, @karstenkoehler’s and/or-branch approach in the association-label threads does the same job and is worth finding.

Longer write-up with the reasoning: HubSpot Workflow Not Firing? Check This Filter | OpsEthic

Hi @Pietro87 and welcome, it’s a pleasure to have you here!

Thanks for sharing this with the HubSpot Community! I’m sure it will help many other Community Members!

Could you also please share the link to the topic where Karsten mentioned the an/or branch approach? The could also be helpful!

Thanks so much and have a lovely day!

Bérangère

Hi @Pietro87

Here is another workaround that we can use to fix this association issue.

Instead of building a separate list and using a branch, you can just fix it at the filter level directly.

The issue was using a " not associated " type filter, which HubSpot silently accepts but never actually evaluates. But there’s a simpler fix: deals with no associated contacts usually have their “Number of associated contacts” property set to 0, not " unknown." So instead of filtering for “unknown,” just filter for:

Number of associated contacts = 0

This is a normal numeric filter, so it works fine in both the trigger and in branches; no need for the list workaround.

Just double-check first: pick a few deals you know have zero associated contacts and confirm the property actually shows 0 for them before rolling it out.