Salesforce Lead Routing: Rule Order Is the Policy, and Round Robin Is a Build

Salesforce ships lead routing on its cheapest paid tier. Its Sales Cloud pricing page lists "Built-in Sales Flows and Lead Routing" among the Starter Suite features, alongside lead, account, contact and opportunity management. So the capability is not a purchase decision for most teams.

What is a decision, and an expensive one, is that the thing Salesforce ships is Assignment Rules, and Assignment Rules have two behaviours that surprise people after go-live. They evaluate top to bottom and stop at the first match, which means the order of your rules is the actual policy. And there is no native round robin, so the fair-distribution feature every team wants has to be constructed out of parts.

Neither of those is a defect. Both are invisible in the configuration screen, which is the problem.

Salesforce lead routing is also searched as SFDC lead routing, and the two names describe the same machinery: assignment rules, Flow and Omni-Channel deciding which rep owns an arriving lead record.

Rule order is the policy

An assignment rule is a list of rule entries with a sort order. Salesforce evaluates them in that order and stops at the first entry whose criteria match. Everything below a matching entry is not consulted.

The consequence is that two teams with identical rule entries in different orders have different routing policies, and both configurations look correct. A named-account entry sitting below a territory entry does nothing at all: every record that matches the territory is assigned and the evaluation stops before it reaches the strategic account you specifically wanted handled differently.

This is why the routing conversation belongs to the sales lead rather than to the administrator. Write the order down in plain sentences first, get it agreed as a policy, and configure second. Most routing arguments are policy arguments that were never had, resurfacing months later as a complaint about a tool.

The vendor-neutral version of that argument, including the rule bases that compose well and the four measurements worth taking, is in our lead routing entry. What follows is what is specific to the instrument.

1. Step 1Record is created or edited

   Assignment runs at that moment, against the field values as they stand

2. Step 2Entry 1 criteria tested

   If it matches, the owner is written and evaluation stops here

3. Step 3Entries 2..n tested in sort order

   Only reached because every entry above them failed to match

4. Step 4Catch-all entry with no criteria

   The last entry, matching everything, so no record can leave with the default owner

The catch-all entry is not optional

Every routing configuration needs a final rule entry with no criteria at all, assigning to a named person.

The instinct is to treat that as an admission that the rules are incomplete, and to keep adding criteria until it is never reached. That is the wrong direction, and the reason is specific to how routing fails.

A routing rule that misfires does not throw an error. From the system's point of view nothing went wrong: an entry was evaluated, a value was written, the record was saved. If no entry matched, the record simply keeps the owner it had, which is normally whoever or whatever created it. There is no exception, no failed job, no red mark on any dashboard. The only symptom is a lead nobody works, and the only person who notices is the buyer who never got an answer.

A badly routed record is visible: it sits on somebody's list, they read it, they say this is not mine, it moves. An unrouted record has no list to sit on.

So the catch-all entry converts a silent failure into a visible one, and the report that goes with it is the count of records with an owner and no activity, aged past whatever your own answer window is. Those two things take an afternoon and they are worth more than another quarter of rule refinement.

Round robin has to be built

Salesforce does not ship a round-robin function. The platform provides everything needed to build one, which is a different statement and the one that matters for scoping.

The standard construction is a numeric field on the Lead that cycles through a range, populated as the record is created, with one rule entry per value in the range pointing at one owner. Sort order 1 tests the field for 1 and assigns to the first person, sort order 2 tests for 2, and so on. Whatever populates that field, whether a formula, a Flow or an external tool, is the actual distribution mechanism, and the rule entries are just the lookup table.

Two things break this in practice, and they break it quietly.

The first is that the rule entries encode your team. Somebody leaves, somebody joins, somebody goes on holiday, and the lookup table still names them. Records keep being assigned to a person who is not there, which is the unrouted failure wearing a valid owner's name, and it is even harder to see because every report shows the record as owned.

The second is that round robin is fairness, and fairness and speed genuinely fight. The fair rule says every rep should get a comparable share of the good inbound, which has real commercial force behind it: nobody stays on a team where the best accounts always land on the same desk. The speed rule says the record should go to whoever can work it now. The compromise most teams land on is to let fairness govern the assignment and a separate mechanism govern the timing, so anybody available can work an unattended record after a short window. That requires somebody to decide the window and write it down. The failure modes specific to the distribution method itself are covered in round-robin assignment.

Deduplication has to run before assignment

The check that decides whether this record is already in the system has to happen before any assignment entry fires, and it is the step teams skip because it feels like a data problem rather than a routing one.

It is a routing problem. A record that already belongs to somebody, arriving again under a slightly different company string or a personal address instead of a work one, is routed by the rules as though it were new. Two people now own the same buyer, both have been alerted, and both think they are first contact. The system built to prevent that collision has manufactured one, and it will do it again every time that buyer comes back.

Salesforce's Lead and Account objects make this sharper than it sounds, because a lead that duplicates an existing account splits the picture across two objects rather than two records. The identity question underneath it is record matching, and the worked example of what two systems disagreeing about identity does to a CRM is in our guide to Apollo and HubSpot deduplication, whose reasoning transfers directly.

A routing setup that fails visibly

• ✓Yes: Rule order agreed as a written policy by the sales lead before configuration
• ✓Yes: A final rule entry with no criteria, assigning to one named person
• ✓Yes: Deduplication running before assignment, not as a monthly cleanup
• ✓Yes: A scheduled report of owned records with no activity past your answer window
• ✓Yes: Round-robin rule entries reviewed whenever someone joins or leaves
• ✓Yes: Reassignment rate and the count reaching the catch-all both on a report somebody reads
• ✓Yes: Records created by an integration confirmed to be running through assignment at all
• ✕No: Unmatched records left with whatever owner the creating process gave them

The integration case, which is where most surprises live

Assignment rules run when a record is created or edited in the interface. Records arriving from an integration, an import or an API call are the case to test explicitly rather than assume, because whether assignment fires for them depends on how the creating process is configured.

The way to find out is not to read documentation about your own stack. It is to create five records the way your integrations create them, and look at the owner field afterwards. If the owner is the integration user, assignment did not run, and every lead your forms or your sourcing tool creates has been landing in one place.

That failure has a distinctive signature worth recognising: a single user owning an implausible number of leads, none of them worked. It is usually discovered by accident, months in, by somebody building an unrelated report.

What routing cannot do

Routing decides who owns a record, which only matters if the record was worth having and if there is a supply of them.

At small volume it is not worth its complexity. If a person could plausibly assign every arriving lead by hand, do that and spend the time on the answer instead. Routing earns its cost at the volume where nobody can hold the queue in their head.

At any volume it is downstream of two questions it cannot influence. Who belongs on the list at all is the ideal customer profile. Whether the arriving record is worth a rep's time is lead qualification, and it is a different gate from routing even though the two get configured in the same afternoon.

And routing produces nothing. A perfectly ordered rule set operating on four inbound leads a week is a well-governed trickle. If the constraint is the number of qualified conversations rather than their distribution, that is a different project, and it is the one we run.

Where we sit

RevenueFlow does not implement Salesforce, resell it, or take a fee for configuring it. We run cold email and LinkedIn outbound on Email Bison and HeyReach, and this is a documentation-grounded account rather than a walkthrough of an org we administer.

Our own interest in routing is narrow and specific: our campaigns send one message per prospect with nothing scheduled behind it, so a reply is the entire signal, and the gap between a reply arriving and a human answering it is the most expensive gap in the motion. That is the same argument the routing layer exists to serve, one step earlier. If the constraint is the volume of replies rather than their assignment, we will build the first campaign on your own market.

For orientation on what else the platform costs, Salesforce's alternatives and Pipedrive against Salesforce cover the comparison buyers run most often.

The Starter Suite feature list, including built-in Sales Flows and Lead Routing, is per Salesforce's own Sales Cloud pricing page, fetched 15 August 2026. Assignment rule behaviour should be confirmed against Salesforce Help for your own edition before you build on it. Verify current terms with the vendor before relying on them.