Lead Assignment Rules Salesforce: How Salesforce Lead Assignment Rules Work, Their Limits, and Round Robin Routing

How do lead assignment rules work in Salesforce?

A Salesforce lead assignment rule is a container. The routing logic lives in the rule entries inside it, and each entry pairs a set of criteria with a destination, either a user or a queue.

Evaluation is simpler than most people expect and that simplicity is the whole design. Entries run in sort order from the top. The first entry whose criteria the lead matches wins, and evaluation stops there. Nothing below it is considered, and no second entry can add to the outcome. That makes ordering the entire craft of building a rule: narrow entries go above broad ones, or the broad ones swallow everything beneath them.

A lead that matches no entry at all is not left ownerless. It falls to the Default Lead Owner set in Lead Settings, and Cases fall to the Default Case Owner. That fallback is worth setting deliberately, because on a lot of orgs it is still pointing at whoever set the org up years ago, which means unmatched leads accumulate silently in one person queue.

The mental model to carry into the rest of this page: assignment rules are a lookup table, not a scheduler. They evaluate the record in front of them and nothing else. They hold no memory of the previous lead, which is why they cannot rotate.

The limits: one active rule, 3,000 entries, 25 criteria per entry

Three numbers define what you can build, and only one of them is likely to constrain you.

One assignment rule can be active per object at a time. Leads get one, Cases get one. You can create and store many rules, but exactly one drives automatic assignment. This is the limit teams actually hit, because it forces every team, region and product line into one ordered list that everybody has to edit without breaking anybody else.

Up to 3,000 rule entries per rule. Salesforce documents the entry cap for assignment, auto-response and escalation rules alike. In practice nobody reaches 3,000 entries, because a rule becomes unmaintainable by a human somewhere around eighty.

Up to 25 filter criteria per rule entry. If a single entry needs more conditions than that, the escape hatch is to switch the entry from criteria to a formula that evaluates to true, which folds the extra logic into one expression at the cost of readability.

The practical ceiling is none of these numbers. It is the fact that one ordered list has one owner, and every change to it risks every other team routing. That is the point at which orgs start looking at a routing layer, not because they ran out of entries.

Which entry points actually run the rule, and which quietly do not

This is the source of most of the "the rule is correct but it did not fire" tickets, and the answer differs by how the lead was created.

Web-to-Lead runs the active rule automatically. Nothing to configure.

Lead import runs it if the person importing opts in during the import wizard. If they did not tick it, every imported lead belongs to the importer.

A lead created manually in the UI runs the rule only if the "Assign using active assignment rule" checkbox is ticked on the edit page. That checkbox has to be on the page layout to exist at all, and it is per save rather than sticky, so it is skipped constantly. The same checkbox is what makes assignment rules run on an update, which is why a lead that is edited does not silently rebound to a different owner.

The REST API applies the active rules by default. The Salesforce REST API Developer Guide documents the Sforce-Auto-Assign header for Accounts, Cases and Leads: set to true, active assignment rules are applied; set to false, they are not; set to a valid AssignmentRule ID, that rule is applied. When the header is not provided at all, REST defaults to applying the active rules.

Apex DML does not. Inserting a Lead in Apex bypasses assignment rules unless the code explicitly attaches Database.DMLOptions and sets assignmentRuleHeader.useDefaultRule = true. This asymmetry is why leads from a custom integration so reliably land on the integration user while leads from the same vendor over REST route correctly.

The documented way to run a second rule that is not the active one

The one-active-rule limit has a documented exception that is worth knowing before anybody rebuilds a rule set around it.

Alongside useDefaultRule, the Apex Database.DMLOptions.AssignmentRuleHeader class exposes assignmentRuleId, which specifies the ID of a specific assignment rule to run for the case or lead. The Apex reference is explicit that the assignment rule can be active or inactive.

So a second rule set can exist and be invoked deliberately, from Apex or from an invocable action called by Flow, without ever being the active rule. That is genuinely useful for a distinct inbound channel: a partner integration, a specific campaign, or a region whose logic has nothing to do with the main list.

The honest caveat is what it costs. Routing now lives in two places, one of them code, and the org has no single screen showing which rule handled a given lead. It solves the technical limit and adds an operational one. It is a good answer for one deliberate exception and a bad answer for five.

Why Salesforce assignment rules cannot do round robin

Not "do not by default" and not "need a workaround first". Salesforce assignment rules structurally cannot rotate, at any edition, and the reason is worth understanding because it tells you what any workaround has to supply.

Criteria evaluate the record in front of them. Whose turn it is depends on who received the previous record. Nothing on the incoming lead knows about the previous lead, so no set of criteria can express turn order. To rotate, something has to store a position between records, and assignment rules have nowhere to store it.

That is why every native round robin recipe is really a recipe for building that storage. The classic is a numbering formula field plus a custom setting holding a counter, incremented by a Flow or trigger on insert, with rule entries keyed to the counter value. It works. It also encodes your team roster into a formula, so onboarding a rep means editing the formula, offboarding one means editing it again, and a rep on vacation keeps receiving leads because the counter has no concept of availability. Teams also discover the second-order problem: two parallel automations sharing one counter drift out of sequence.

The variants people reach for next, a Flow with a decision element per rep, or queue-based assignment with agents pulling work, each trade one problem for another. Queues in particular remove rotation entirely and replace it with cherry picking.

When native rules are the right call, and when to add a layer

Native assignment rules are free, supported, well understood by every Salesforce admin, and fast. There is no virtue in replacing them when they fit, and they fit more often than vendors admit.

Stay native when your routing is criteria only and reasonably stable: leads route by territory, source or product to a named owner or a queue, one team owns the rule, and nobody is asking for fairness between individuals. Add the Default Lead Owner, put the assignment checkbox on the layout, and you are finished.

Add a layer when any of these becomes true. Volume has to be shared fairly between individuals rather than landed on a team. People go on vacation and leads should stop reaching them without anybody editing a rule. Different regions or products need genuinely independent rule sets that do not sit in one ordered list. Reps ask why they did not get a lead and nobody can answer from an owner field. Or the same routing question needs answering for support tickets and internal requests, which native lead assignment rules do not touch at all.

Assigner is that layer, and it is deliberately not a replacement for Salesforce. Salesforce stays the system of record. Assigner decides who gets the record, using true circular round robin, weighted rotation, workload limits, skills and live availability, and it records the rule, the candidates and the reason behind every assignment. Pricing is $12 per user per month billed yearly ($15/mo billed monthly). For the cross-CRM picture, including how HubSpot, Dynamics 365 and Zoho answer the same question, see lead assignment rules software compared across four CRMs.

Do Salesforce lead assignment rules support round robin?

Not natively. Salesforce assignment rules match each lead to the first rule entry whose criteria it meets, with no built-in round-robin or load balancing. Teams add rotation with a numbering formula field, a Flow, or an AppExchange app. Assigner applies round-robin, weighted round-robin, and workload balancing out of the box across leads, tickets, and ops tasks.

How many active lead assignment rules can you have in Salesforce?

Only one assignment rule can be active per object at a time, though that rule can hold many ordered entries. Leads and Cases each get their own single active rule. If different teams need different logic running at once, you manage it through entry order in that one rule, which grows hard to maintain. Assigner lets independent rule sets run in parallel.

Are Salesforce lead assignment rules free?

Yes. Assignment rules are included with Salesforce at no extra cost, which is a real advantage when your routing is simple and static. The cost shows up later as admin time spent maintaining formula-field round-robin hacks and Flows. Assigner is a paid layer priced at $12 per user that replaces those workarounds with built-in fair distribution and availability.

Can Salesforce assignment rules route by workload or availability?

No. Native assignment rules evaluate static criteria only; they do not check how many open records a rep already holds or whether that rep is working today, so a rule can assign to someone on vacation. Assigner routes by current workload and respects availability, working hours, and time zones so nothing lands on an absent rep.

Can you edit Salesforce assignment rules without admin access?

No. Editing assignment rules requires Setup access, so a sales manager or support lead usually files a request with a Salesforce admin to change routing, which slows every adjustment. Assigner lets the person who owns the process edit rules directly and shows the reason behind each assignment, so changes are easy to make and verify.

How many lead assignment rule entries can you have in Salesforce?

Salesforce allows up to 3,000 rule entries per rule, and up to 25 filter criteria within a single rule entry. If one entry needs more conditions than that, switch it from criteria to a formula that evaluates to true. The limit teams actually hit is not the entry count but the single active rule, which forces every team into one ordered list.

Do Salesforce assignment rules run when a lead is created by the API?

Over REST, yes by default. The Sforce-Auto-Assign header controls it for Accounts, Cases and Leads, and when the header is not supplied REST applies the active assignment rules. Apex is the opposite: a Lead inserted in Apex bypasses assignment rules unless the code attaches Database.DMLOptions and sets assignmentRuleHeader.useDefaultRule to true.

Do Salesforce assignment rules run when a lead is updated?

Only if the Assign using active assignment rule checkbox is ticked on that save. The checkbox has to be present on the page layout to exist at all, and it does not stay ticked between saves, so it gets skipped routinely. That is deliberate: it stops an edited lead from silently rebounding to a different owner mid-conversation.

What happens if a lead matches no assignment rule entry?

It goes to the Default Lead Owner configured in Lead Settings, and an unmatched Case goes to the Default Case Owner. Nothing is left ownerless. Check what yours is set to, because on many orgs it still points at whoever configured Salesforce originally, which means unmatched leads quietly pile up in one personal queue nobody reviews.

Can you run more than one assignment rule in Salesforce?

Only one rule per object is active at a time, but there is a documented exception. The Apex AssignmentRuleHeader exposes assignmentRuleId, which runs a specific rule by ID, and the Apex reference states that rule can be active or inactive. So a second rule set can be invoked deliberately from code or Flow. The cost is that routing then lives in two places.