Salesforce Lead Assignment Rules Not Working: Causes and Fixes

Salesforce lead assignment rules usually fail for one of a few reasons: the rule is inactive, only one active rule exists, the record was created by an API or import that skipped the rule, the "Assign using active assignment rule" box was not checked, entry criteria did not match, or the order of execution handed the record off before your rule ran. Work through those causes in order and most "not working" cases resolve quickly. Below is each cause, how to confirm it, and how to fix it.

Why are my Salesforce lead assignment rules not working?

The single most common reason is that the assignment rule never fired at all, not that it fired incorrectly. Salesforce runs only one active lead assignment rule at a time, and it runs only when a record is created or edited with the assignment box selected or the API set to trigger it. If any link in that chain is missing, the lead keeps its current owner and it looks broken. Start by confirming the rule is active, then confirm the record actually triggered it.

The rule is inactive or you have more than one

Salesforce allows many assignment rules but only one active rule per object. If someone created a second rule and marked it active, it silently replaced the one you expected. Go to Setup, Lead Assignment Rules, and confirm exactly one rule is marked Active and it is the right one. All of your rule entries live inside that single active rule as ordered lines, not as separate rules.

The assignment box was never checked

When you create or edit a lead by hand, Salesforce only applies the active assignment rule if the "Assign using active assignment rule" checkbox is selected on the page, or if a default is forced. Manual edits, list view inline edits, and many quick actions leave it unchecked, so the rule is skipped. To force it every time, you generally need the record inserted through a flow, an Apex trigger, or a process that sets the assignment rule header, rather than relying on a user remembering the checkbox.

Leads created by API, import, or web-to-lead skipped the rule

Records inserted by the API, Data Loader, or an integration do not run assignment rules unless the call explicitly sets the AssignmentRuleHeader to true. This is the quiet killer behind "the rule works when I test it by hand but not for real leads." Web-to-lead does run the active rule, but Data Loader and custom integrations do not by default. Fix it by setting the assignment rule header in the API call, or by moving assignment into a flow or trigger that always runs.

Order of execution assigned the owner first

Salesforce processes a save in a fixed order of execution. Before-save flows and before triggers run first and can set the OwnerId, and assignment rules run later in that sequence. If a before-save automation stamps an owner, the assignment rule may still overwrite it, or your own logic may fight the rule and produce a result that looks random. When a rule and a flow both touch ownership, decide which one owns the decision and remove the other so they stop colliding. For a step-by-step map of exactly where the rule fires, see the Salesforce lead assignment rules order of execution.

Entry criteria did not match the lead

Every rule entry has criteria, and a lead that matches none of them falls through to the default lead owner. Common traps: a picklist value that changed, a country or state formatted differently than the rule expects (for example "US" versus "United States"), a blank field the rule tests, or rule entries in the wrong order so a broad early entry catches leads before a specific later one. Reorder entries most-specific first, and widen or correct the criteria that real leads actually carry.

You are trying to do true round-robin

Native Salesforce assignment rules match a lead to a queue or user by criteria. They do not, on their own, rotate leads evenly across a team or weight the split by who is available or already buried. Admins who try to fake round-robin with a counter field, a formula, and a stack of rule entries usually end up with the brittle setup that "stops working" the moment someone is out or the field drifts. Round-robin that stays fair under real conditions needs either heavy custom Apex or a dedicated tool.

A quick diagnostic table

How to make Salesforce lead assignment reliable and fair

Once the plumbing works, the harder problem is fairness: rotating leads evenly, weighting by capacity, skipping reps who are out, and being able to explain why each lead landed where it did. That is where native assignment rules run out of room, and where teams reach for a custom build or a companion tool. It is also worth revisiting the rule design itself, since many "broken" rule sets are really ordering and fallback problems: our guide to writing lead routing rules covers the four parts every rule needs and the mistakes that quietly misroute leads. A common, lighter path is to keep Salesforce as your system of record and add a fair rotation layer beside it, so you get round-robin assignment weighted by workload and availability without a RevOps-scale contract.

If your leads arrive from many places (forms, chat, ads, partners, a spreadsheet), the reliability problem often starts before Salesforce even sees them, so it helps to connect those apps and databases into one clean flow first, then route from a single, trustworthy source. From there, round-robin lead assignment beside Salesforce gives you fair, explainable rotation without fighting the order of execution or maintaining counter fields that break. If you are still working out which native mechanism should own each segment, our walkthrough of how to assign leads in Salesforce compares assignment rules, Flow, queues, and bulk reassignment side by side.

Frequently asked questions

Do Salesforce lead assignment rules run on update?

Only if the update triggers them. A rule runs on edit when the user checks "Assign using active assignment rule" or when an API or automation sets the assignment header on the update. A plain field edit does not re-run the rule, which is why an existing lead can keep an owner you expected the rule to change.

Why do some leads go to the default lead owner?

Because no rule entry matched them. When a lead meets none of the active rule's criteria, Salesforce assigns it to the default lead owner as a fallback. Check for formatting mismatches, blank fields your criteria test, and entry order, since a broad entry near the top can catch leads meant for a more specific entry below it.

Can Salesforce do round-robin lead assignment natively?

Not in a durable way. Native assignment rules match by criteria, not by rotation, so true round-robin needs custom Apex with a counter or a dedicated routing tool. Weighting the rotation by capacity or availability pushes past what native rules do, which is why teams add a fair round-robin layer beside the CRM. If the workarounds are piling up, compare the native feature with a dedicated Salesforce lead assignment rules alternative that adds round-robin, load balancing, and availability out of the box.

What is the order of execution for assignment rules?

Assignment rules run after before-save flows and before triggers, and after most validation, but before after triggers and roll-up updates. Because earlier steps can set the owner, a before-save automation and an assignment rule can both touch ownership in one save. Decide which one is authoritative and remove the other to stop conflicts.