Three workflows, enabled and enrolling nobody

The symptom

Three workflows were meant to catch deposit deals missing an Estate association and notify the team. Nobody had ever been notified. The obvious readings — wrong trigger, disabled, nobody matching the criteria — were all wrong. The workflows were enabled, the criteria looked right in the builder, and plenty of records matched.

The cause

Association absence cannot be expressed with a NOT_IN_LIST filter. The Lists API rejects it outright — try to save such a list and you get an error. The Workflows API accepts exactly the same filter, stores it, and leaves it permanently inert.

There is no error. No warning in the UI, nothing in the workflow history, nothing to distinguish it from a workflow that is simply waiting for a record to match. It looks correct in the builder because the builder renders what was stored, and what was stored is syntactically fine and semantically dead.

This is the worst class of platform defect: one that fails closed, silently, in the direction of doing nothing.

The fix

The working pattern is a list branch on IN_LIST — the positive form the Lists API will accept — with the notification on the DEFAULT path. Records that do have the association go down the branch; everything else falls through to default, which is the set you actually wanted.

Branch semantics were verified against real data before anything was enabled, using two throwaway lists: 453 of 662 deposit deals carried an Estate association, so 209 did not. A 209-deal association census then showed 0% missing the Home association, 8.1% missing Estate, and 17.7% with a blank client address.

All three workflows were date-bounded before being enabled, so switching them on did not retro-blast several years of historical deals with notifications.

Why this matters beyond one portal

A configuration audit would have passed these workflows. They are configured correctly by every visible measure. Only the action log — what actually ran — showed that nothing had.

That is the rule this work runs on: configuration says what a system could do, and only the action log says what it did. Any finding derived from configuration alone stays a hypothesis until behaviour confirms it. Applied properly across one portal's audit claims, roughly a third of confidently-stated configuration inferences turned out to be wrong or overstated.