Your Lead Routing Probably Does Not Do What You Think

A sales director asked why leads were not reaching the right regional consultants. The routing had four regional branches. It had two rotation pools. It had been that way for years, and it looked entirely correct in the builder the whole time.

This failure is not specific to one CRM. Anywhere routing branches on a condition and then assigns from a pool — HubSpot workflows, Salesforce assignment rules, a queue in a custom system — the branch count and the pool count can drift apart, and nothing validates that they match.

The ten-minute audit

Two numbers, compared:

1. Count the branches. How many distinct outcomes is the routing supposed to produce? Territories, segments, product lines, whatever the business thinks it is splitting on.
2. Count the pools. How many distinct assignment pools, queues or user sets do those branches actually feed?

If there are more branches than pools, some branches are merging. The distinction you believe you are making is not being made, and it has not been for however long the routing has looked fine.

In the case above: three workflows each branched North, South, East, Geelong and West, and then rotated into two pools. North and South-East went to one; Geelong and West went to the other. The regional branching was entirely decorative.

Why builders cannot show you this

Because a builder renders structure, not effect. The four-way branch genuinely exists and genuinely evaluates. What collapses is what happens after the branch — two paths pointing at the same pool produce identical behaviour while looking like two different paths on the canvas.

Nothing here is misconfigured in a way a validator would catch. Which is precisely why these survive for years and why a configuration audit passes them. It is the same rule that applies to workflows that are enabled and enrol nobody: configuration says what a system could do, and only behaviour says what it did.

Derive the territory map from ownership, not from the document

When you rebuild the routing, the temptation is to take the territory map from whatever document defines it. Don’t. That document describes intent at the moment somebody wrote it. Record ownership describes what has actually happened since.

Re-deriving the map from current-year ownership on that engagement corrected two entries in the documented version — one consultant turned out to be 95.3% in a region the document had recorded as blended, another 97.2% in a different one. Both had been routed on the wrong assumption.

Derive from the data, then reconcile against the document and ask about the differences. The gaps are usually the interesting part: a territory that quietly changed, a rep who moved, a market nobody formally reassigned.

Routing and visibility are different systems

The complaint that started this audit was about visibility — two people could see records they should not. The obvious cause was a recent team change, and reversing it would have been quick, satisfying and wrong.

The actual cause was a permission set with its contact scope set to all records, and it predated the engagement entirely. Separately, an unassigned-records toggle on the deal view was exposing 76 ownerless deals to everyone.

Assignment and visibility interact but they are not the same machinery. Audit them separately, and resist fixing the thing you were blamed for when it is not the thing causing the problem.

Verify after writing, not before

Rebuilding that routing meant repointing nine rotate actions across three workflows, with the existing pools kept alongside the new ones so the rotation never emptied mid-change. Then four separate checks: rules read back, users read back, the teams interface confirmed independently, and every unrelated user, team and overwrite flag confirmed unchanged.

That last part is not paranoia. Some platform writes are accepted and silently dropped — HubSpot multi-select report filters can lose values on save, and the only way to know is to read the filter back after writing it. Trusting a success response is how a change that did not happen gets reported as done.

Common questions

Full write-up in four branches, two pools, and nobody knew. This kind of audit is not CRM-specific — the diagnostic works on any modern revenue stack, and the engineering to fix it follows.