Synthetic lead-routing rule table: eight leads, four rules and a fallback

An invented rule set

Everything here is made up: the people, the rules and the leads. The first matching rule wins, and a lead that matches nothing goes to a named fallback owner with an alert. The rules are written so that someone can decide, for any lead, what the correct owner is without asking anyone. A routing test is only useful if its expected owners were written down before the workflow was built or changed.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

Rules, first match wins
R1  employees 250 or more                      -> Amira
R2  country GB or IE and interest Reports      -> Ben and Chloe, shared equally
R3  country GB or IE                           -> Ben
R4  interest Reports                           -> Chloe
Fallback (nothing matched)                     -> Dev, with an alert

Eight leads and the owners they should reach

Each lead is chosen to test something: a boundary, a rule that should lose to an earlier one, a blank field, a lead that matches nothing. L2 and L3 share rule R2, whose pool is Ben and Chloe. Each of them must reach a member of that pool, and the split between the two is reported, not asserted: HubSpot documents equal distribution by default, but two leads cannot show it, so the test log records who received each.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

lead  employees  country  interest  expected owner   rule
L1    400        GB       Reports   Amira            R1 (beats R2: first match wins)
L2    20         GB       Reports   Ben or Chloe     R2 (pool member; split reported, not asserted)
L3    20         IE       Reports   Ben or Chloe     R2 (pool member; split reported, not asserted)
L4    20         GB       Billing   Ben              R3
L5    20         FR       Reports   Chloe            R4
L6    20         FR       Billing   Dev              fallback, alert sent
L7    (blank)    GB       Billing   Ben              R3 (blank does not meet R1)
L8    250        US       Billing   Amira            R1 (250 counts: boundary)

Change the pool and test again

For contact-based workflows, which this example assumes, the documentation says rotation counts reset when owners are added or removed, so a pool change is a test in its own right. (HubSpot says the reset rules do not apply to lead-based or ticket-based workflows.) Remove Chloe from the R2 pool and send three more small GB leads interested in Reports. All three should go to Ben, and none to Chloe. Then check that R4 still sends a French Reports lead to Chloe, because she is still an owner under a different rule. Record the expected and actual owner side by side for every lead.

• Three further leads after the pool change: all expected for Ben.
• One R4 lead: still expected for Chloe.
• One lead that matches nothing: Dev, with the alert.

What was checked, and what was not

The expected owners above were worked out with a short script implementing the rule order, run on 11 October 2026, so the table is internally consistent. No HubSpot account, workflow or real lead was used, and the example does not show that a particular workflow behaves this way. Treat it as the specification you would approve before a build.

The paid routing outcome takes your own rule table, with up to six rules and a named fallback, and is accepted by synthetic leads in the style above: one for each rule, a second for a shared pool, one for each agreed edge case, one for the fallback and one that already has an owner, then three more after a pool change. A standing service checks each week that new leads still have owners.