Lead Assignment Rules Not Working in Salesforce (and When to Use Flow)

An assignment rule runs only when the process that saves the lead asks for it. The rule can be active and correct and still never touch a lead, because the form, integration or flow that created the record did not ask for it. The table below is the order we check things in when a client says their rules stopped working.

Why is my lead assignment rule not working?

Sources, read 16 October 2026: Salesforce Help on assignment rules that fail to set the Owner (activation, criteria, the layout checkbox), Guidelines for Assignment Rules (one rule in effect at a time), running rules only when a lead is created and the Apply Lead Assignment Rules action on the Run Immediately path; the developer guides for the REST Assignment Rule header, the SOAP AssignmentRuleHeader and Apex DMLOptions.

How do you tell which path created the lead?

Start from the lead that went wrong, not from the rule. Three fields usually settle it:

• Created By. An integration user means an API path, so the question becomes which API and which headers. A person means the user interface, so check the page layout. An automated process user or the flow's running user means Flow or Apex.
• Lead Owner history. Turn on field history for Lead Owner. A lead that was assigned and then changed points at a second automation, often a flow that sets the owner after the rule ran, or an edit that ran the rule again.
• Lead Source and record type. If one source or record type is the only one failing, compare its intake path with one that works before touching the rule entries.

How do you run assignment rules from Apex or the API?

In Apex, attach DML options to the record before the insert. Salesforce's DMLOptions reference notes that these options take effect only for Apex DML, not for saves in the user interface.

// Run the active lead assignment rule on an Apex insert.
Database.DMLOptions dmo = new Database.DMLOptions();
dmo.assignmentRuleHeader.useDefaultRule = true;

Lead lead = new Lead(LastName = 'Example', Company = 'Example Co');
lead.setOptions(dmo);
insert lead;

Over REST, the header decides. When it is absent, REST applies the active assignment rule; FALSE skips rules and a rule ID applies that specific rule (Assignment Rule header). SOAP is the reverse: no rule runs unless the call includes the AssignmentRuleHeader with useDefaultRule or a rule ID. Two integrations writing to the same org can therefore behave in opposite ways with no difference in their field mapping.

POST /services/data/v68.0/sobjects/Lead
Sforce-Auto-Assign: TRUE        // the default when the header is absent
Content-Type: application/json

{ "LastName": "Example", "Company": "Example Co" }

When should a Flow assign the lead instead of an assignment rule?

Assignment rules are good at one job: reading fields on the lead and picking an owner from a list. They cannot look at another record, so a rule cannot say “give it to whoever owns the account with this email domain”. They also cannot log why they chose an owner. When either of those matters, build the decision as a record-triggered flow on Lead that runs on create only:

1. On the asynchronous path, look up an existing relationship: a Contact with the same email, an Account matched by domain, or an open Opportunity.
2. If one exists, set the owner to that record's owner and write the reason to a routing field.
3. If none exists, call the standard Apply Lead Assignment Rules action so your rule entries still own the field-based decisions. It runs the active rule on up to 20 leads at a time and is available from API version 54.0.
4. Add a fault path that assigns a staffed queue and alerts someone, so a failed lookup never leaves the lead with the integration user.

The asynchronous path matters. Salesforce Help documents that when a lead is saved in the UI with the assignment checkbox cleared, the Apply Lead Assignment Rules action does nothing on the flow's Run Immediately path and works on the asynchronous one (Knowledge Article 003324281, published 24 September 2026). For the full precedence order and where round robin and Omni-Channel fit, see Salesforce lead routing architecture.

What did our own org show about assignment rules?

Our own Salesforce org is a small, clean example of the problem, and it is set up this way on purpose. Website leads are created by an n8n workflow over the REST API, and the workflow never sets the owner. The org has no active lead assignment rule, and the Lead page layout leaves the assignment checkbox unselected by default. With one person owning every lead, that is the right amount of routing. The intake also checks for an existing lead with the same email first and logs a repeat submission as a Task, so a returning visitor keeps the owner they already have. The field-by-field intake is in how we tie every ad lead to a Salesforce Campaign.

The setup also shows how the same rule would behave in two different ways the day we activate one. Because REST applies the active rule by default, every website lead would be assigned immediately with no change to the workflow. A lead typed in by hand would still keep its creator as owner, because the layout does not select the checkbox. Neither behaviour shows on the rule's own setup page, which is why the checklist below starts with the entry points rather than the rule entries.

What should you check before activating a lead assignment rule?

1. List every path that creates leads: web forms, Web-to-Lead, imports, each integration, each flow, Apex and manual entry.
2. For each path, write down whether it requests assignment today (checkbox, header, DML options or the Flow action), and whether it should.
3. Order the entries from most specific to least specific, and end with a catch-all to a staffed queue.
4. Decide whether edits may reassign, and set the layout default to match.
5. Test one lead per path in a sandbox and check Created By and Lead Owner on each.
6. Turn on Lead Owner field history before go-live, so the first wrong assignment can be traced the same day.

A duplicate check belongs in front of all of this, because a rule that assigns a second copy of an existing lead to a second rep has worked as configured and still created a problem. The pattern we use is in how to handle duplicate leads in Salesforce, and our intake workflow is described in n8n and Salesforce automations.

Frequently asked questions