Four branches, two pools, and nobody knew

The complaint, and the wrong answer

The reported problem was visibility: two consultants could suddenly see records they should not. The obvious cause was a recent team change, and it would have been easy to reverse that change, declare it fixed, and move on.

It was not the cause. The audit of all ten lead-assignment workflows and the user, role and team model showed the visibility came from a permission set with its Contacts scope set to All contacts — nothing to do with teams, and predating the engagement entirely. Separately, an Unassigned tick on the Deals view was exposing 76 ownerless deals.

Fixing the thing you were blamed for is not the same as fixing the problem.

What the audit actually found

All three round-robin workflows branched four ways — North, South, East, Geelong, West — and then rotated into only two pools. North and South-East both rotated to the same pool; Geelong and West both rotated to another. The regional branching was cosmetic. Leads had never been routed by region in the way the business believed.

Teams did drive the rotation — thirteen of fourteen rotate actions used team IDs rather than user IDs — which meant the fix was possible without rebuilding the workflows from scratch. But a separate team change that had been made earlier was inert, because the team it referenced was not used anywhere in the routing.

Rebuilding it against ground truth

The region map was re-derived from actual contact ownership in the current year rather than from the documented territory list. That corrected two entries the earlier analysis had wrong — one consultant was 95.3% North rather than the blended figure previously assumed, another 97.2% West.

The four original region teams were restored using two empty teams already present in the portal. A nested sub-team was unnested to top level to remove any ambiguity about whether a parent rotation pulls in child members. Nine rotate actions were repointed across the three workflows, with the existing pools kept alongside the new ones so the rotation never emptied mid-change.

Then it was checked four ways before being called done: workflows read back, users read back, the teams UI confirmed nesting and membership, and every unrelated user, team and overwrite flag was confirmed unchanged.

The habit underneath

Two things made this work. Deriving the territory map from ground truth — who actually owns records — rather than from the document that was supposed to describe it. And checking the change against the portal afterwards instead of trusting the API response, because some HubSpot writes are accepted and silently dropped. Multi-select report filters are the sharpest example: values can vanish on save, and the only way to know is to read the filter back.