Salesforce Lead Assignment Rules Order of Execution, Explained
July 2026 · Assigner
Salesforce lead assignment rules run near the end of the save process, after before-save and after-save triggers, workflow field updates, and most flows, but before the record commits and post-commit logic like roll-up summaries. That late timing is why a field a trigger or flow sets earlier is available to the rule, but why anything that changes the record after assignment can quietly send the lead to the wrong owner.
Where lead assignment rules sit in the order of execution
Salesforce processes every insert or update through a fixed sequence, and assignment rules have a specific slot in it. Knowing that slot is the difference between routing that behaves and routing that mystifies your whole team. Here is the simplified order for a Lead save, with the assignment step called out.
- System validation and required-field checks run first.
- Before-save flows and before triggers fire, so any field they set is in place early.
- Custom validation rules and duplicate rules run.
- The record saves to the database, but is not yet committed.
- After triggers and after-save flows fire.
- Workflow rules run, and if a field update fires, the record saves again and triggers can re-run.
- Escalation rules, then assignment rules, execute.
- Roll-up summary fields recalculate, and the transaction commits.
- Post-commit logic runs: sending assignment emails, async Apex, and outbound work.
The headline is that assignment rules read the record as it stands after triggers, flows, and workflow field updates have already touched it. So if you want to route on a value, that value has to exist by step 6. If something changes the owner after step 7, the assignment rule has no chance to react.
Why the timing breaks lead routing
Most "the assignment rule assigned the wrong person" tickets trace back to one of three timing problems, not to the rule logic itself. If yours are not firing at all rather than firing late, the checklist in Salesforce lead assignment rules not working covers the usual culprits.
| Symptom | Likely cause | Fix |
|---|---|---|
| Rule ignores a field a flow just set | Flow runs after the rule, or in a later save | Set routing fields in a before-save flow or before trigger |
| Lead lands with the wrong owner after import | Assignment rule box not checked on the API or import call | Pass the assignment rule header explicitly on insert |
| Owner flips right after assignment | A later trigger or process changes OwnerId post-commit | Move that logic before assignment or gate it |
| Round-robin skips or double-serves reps | Multiple entry points assign the same lead | Consolidate to one assignment path |
Do assignment rules run on update, or only on insert?
Assignment rules do not run automatically on update. They fire on insert, and on update only when the person or process editing the lead checks the "Assign using active assignment rule" box, or when an API or Apex call passes the assignment rule header. This trips up teams constantly: a lead comes in, gets enriched by a flow an hour later, and everyone expects it to re-route, but it never does because nothing asked the rule to run again. If you need re-assignment on a field change, you have to trigger it deliberately with Apex or a flow that sets the assignment header.
How do you force an assignment rule to run from a flow or Apex?
You force it by setting the assignment rule flag on the DML operation. In a record-triggered flow, use an "Assign using active assignment rules" option or update the record with the flag through an action; in Apex, set Database.DMLOptions with assignmentRuleHeader.useDefaultRule = true before the update. Do this in an after-save context so the record is fully populated, and route on fields that were set earlier in the order of execution. The common mistake is trying to assign in a before-save flow, where the record is not yet in a state the rule can read cleanly.
Keeping assignment predictable
Three habits keep Salesforce routing from drifting into chaos as your rules grow.
Set routing fields early, assign late. Any field the rule depends on (region, product interest, lead score, round-robin bucket) should be populated by a before-save flow or trigger, so it exists well before the assignment step. Then let a single assignment path do the routing.
Use one entry point. When web-to-lead, imports, an integration, and a manual "reassign" button all try to assign the same records, you get skipped reps and duplicate touches. Pick one place where assignment happens and route everything through it. Consolidating entry points is the single biggest reliability win most teams find, and it is exactly what a rules-based assignment engine is built to give you.
Watch what runs after assignment. Any automation that edits OwnerId after step 7 can undo the rule silently. Audit your post-assignment triggers and processes, and either move that logic earlier or gate it so it does not fight the router.
When native assignment rules run out of room
Standard Salesforce assignment rules are ordered lists of criteria that match on the first true entry. That is fine for simple territory or product splits. It gets brittle when you need weighted round-robin, load balancing by current open count, availability by working hours, or skills-based matching, because none of that lives natively in the rule engine and teams end up bolting on Apex and flows that fight the order of execution. Deciding how much of that logic you actually need starts with writing lead routing rules that stay readable as the team grows. If your routing has outgrown ordered criteria, a dedicated engine that handles Salesforce round-robin and skill-and-load routing in one place, and shows why each lead landed where it did, removes most of the timing guesswork. It sits beside Salesforce rather than replacing your rules, so you keep the CRM as the system of record. For a side-by-side view of where native rules stop and a routing layer picks up, see this Salesforce lead assignment rules alternative.
Measure whether the routing actually works
Predictable assignment is the goal, but conversion is the scoreboard. Track which routing paths produce worked leads and closed deals, not just which paths fire, because a rule can be technically correct and still send high-intent leads to reps who never touch them. If pulling those numbers out of Salesforce reports is a chore, letting a tool that turns plain-English questions into database queries answer "which lead source and owner combinations convert best" gets you to the pattern faster than building yet another report. Route on what the data says, then revisit the rules each quarter.
The short version
Lead assignment rules fire late in the Salesforce order of execution, after triggers, flows, and workflow field updates, and only on insert unless you ask them to run on update. Populate routing fields early, assign through one path, keep post-assignment automation from overwriting the owner, and reach for a dedicated routing engine when weighted, load-based, or skills-based logic outgrows native ordered criteria. Get the timing right and Salesforce lead routing stops being a mystery.
Stop hand-sorting your incoming work
Route every ticket, lead, and request to the right available person by skill, workload, and availability, using rules you control, and every assignment shows why. Rules you control, no black box.