How to Force Lead Assignment Rules on New Leads in Salesforce

There’s no built‑in UI way to make the Lead Assignment checkbox required while hiding it — the checkbox maps to the assignment-rule DML header and Salesforce won’t reliably keep it True when the UI doesn’t send it. To force Active Lead Assignment Rules for every new Lead, enforce assignment on save: use an after‑save record‑triggered Flow that calls an invocable Apex (or an Apex after‑insert handler) which re‑runs assignment rules with Database.DMLOptions.assignmentRuleHeader.useDefaultRule = true and a recursion guard.

Contents

• Problem summary and why the checkbox can’t be required
• Why there’s no standard UI to require the Lead Assignment checkbox
• Record‑triggered Flow + Invocable Apex (recommended) to force assignment rules
• Apex-only solution (trigger + handler) to re-run assignment rules
• Implementation caveats: recursion, integrations, notifications, limits
• Quick checklist & troubleshooting steps
• Sources
• Conclusion

Problem summary and why the checkbox can’t be required

You observed the exact, common behavior: when the page layout shows the Lead Assignment checkbox and Default = True, new Leads follow Active Lead Assignment Rules; when you hide that UI control the assignment header isn’t sent and Salesforce ends up assigning the Lead to the creator. That’s expected in many orgs — the page layout control is just a UI toggle, not a persistent “required” field you can enforce centrally. Community answers and field reports recommend programmatic enforcement rather than relying on hiding + default behavior (example discussion: https://stackoverflow.com/questions/79860124/how-do-i-make-auto-lead-assignment-checkbox-required-salesforce).

If your goal is “no user can override — every new Lead must run the org’s Active Lead Assignment Rules,” the only reliable approaches are automation or Apex that runs during/after save and explicitly re‑applies assignment rules.

Why there’s no standard UI to require the Lead Assignment checkbox

The “Assign using active assignment rules” control is not a normal persistent field on the Lead record — it controls the assignmentRuleHeader on the DML operation. Page layout properties change how the UI presents or defaults that control, but they don’t change the underlying DML behavior across every create path (UI, API, integrations). The official assignment‑rules documentation explains how rules are evaluated and highlights that assignment requires passing the header or checking the box when creating the record in the UI: https://help.salesforce.com/s/articleView?id=service.creating_assignment_rules.htm&language=en_US&type=5 and https://help.salesforce.com/s/articleView?id=service.customize_leadrules.htm&language=en_US&type=5.

Because it isn’t a persistent field, you can’t:

• make it “Required” on the page layout,
• reference it directly in validation rules,
• rely on hiding+Default = True to guarantee the header is set from every UI and API path.

That’s why administrators and developers often re‑run assignment rules from Flow or Apex instead of trying to force the UI checkbox.

Record‑triggered Flow + Invocable Apex (recommended) to force assignment rules

Why this pattern: Flows are preferred for admin-friendly automation but Flow cannot set the assignmentRuleHeader on DML by itself. The typical, maintainable pattern is an after‑save (After Insert) record‑triggered Flow that calls an invocable Apex action which performs a Database.update with DMLOptions.assignmentRuleHeader.useDefaultRule = true. This guarantees assignment rules run regardless of whether the UI checkbox was present or unchecked.

Implementation steps (high level)

1. Build assignment rules and test them manually (Setup → Lead Assignment Rules).
2. Create an Apex invocable class (bulkified) that accepts a list of Lead Ids and does a Database.update(leads, dmo) with dmo.assignmentRuleHeader.useDefaultRule = true. Optionally suppress duplicate email notifications with the EmailHeader flags.
3. Create a record‑triggered Flow: Object = Lead, Trigger = After Create (After Save), Run = actions, and add an Apex Action that passes the newly created record Id(s) to your invocable class. Activate the Flow.
4. Test in Sandbox with UI, API, web forms and bulk inserts.

Sample invocable Apex (bulkified, recursion guard)

public class LeadAssignmentInvoker {
 // prevent re-processing inside same transaction
 private static Set<Id> processedIds = new Set<Id>();

 public class Request {
 @InvocableVariable(required=true)
 public Id recordId;
 }

 @InvocableMethod(label='Re-run Lead Assignment Rules')
 public static void runAssignmentRules(List<Request> requests) {
 Set<Id> ids = new Set<Id>();
 for (Request r : requests) if (r != null && r.recordId != null) ids.add(r.recordId);
 ids.removeAll(processedIds);
 if (ids.isEmpty()) return;

 List<Lead> leads = [SELECT Id FROM Lead WHERE Id IN :ids];
 if (leads.isEmpty()) return;

 Database.DMLOptions dmo = new Database.DMLOptions();
 dmo.assignmentRuleHeader.useDefaultRule = true;
 // optional: avoid duplicate user/auto-response emails
 dmo.EmailHeader.triggerUserEmail = false;
 dmo.EmailHeader.triggerAutoResponseEmail = false;

 Database.update(leads, dmo);
 processedIds.addAll(ids);
 }
}

Async variant (Queueable) — use if you want to move the assignment update to a separate transaction (reduces synchronous CPU and risk of hitting limits, but owner may not be set immediately):

• Create a Queueable class that does the same Database.update with DMLOptions.
• Invoke it from the invocable method with System.enqueueJob(new LeadAssignmentQueueable(ids)).

References and walkthroughs on this pattern: https://automationchampion.com/2021/11/01/getting-started-with-salesforce-flow-part-77-running-lead-assignment-rules-from-salesforce-flow/ and practitioner notes: https://opfocus.com/blog/configuring-the-assign-using-active-assignment-rules-checkbox/.

Apex-only solution (trigger + handler) to re-run assignment rules

If you prefer pure Apex (no Flow), implement an after‑insert trigger that calls a bulkified handler which re‑updates the new Leads with DMLOptions. Key points:

• Run this in after insert (so the Lead Id exists).
• Bulkify: collect Ids, build a list of lightweight sObjects (new Lead(Id = …)), set DMLOptions once, call Database.update(list, dmo).
• Use a static Set or static boolean flag in the handler class to prevent recursion (the update will fire update triggers).

Example trigger + handler

trigger LeadAssignmentTrigger on Lead (after insert) {
 if (Trigger.isAfter && Trigger.isInsert) {
 LeadAssignmentHandler.handleAfterInsert(Trigger.new);
 }
}

public class LeadAssignmentHandler {
 private static Set<Id> processed = new Set<Id>();

 public static void handleAfterInsert(List<Lead> newLeads) {
 Set<Id> ids = new Set<Id>();
 for (Lead l : newLeads) if (l.Id != null && !processed.contains(l.Id)) ids.add(l.Id);
 if (ids.isEmpty()) return;

 List<Lead> toUpdate = new List<Lead>();
 for (Id id : ids) toUpdate.add(new Lead(Id = id));

 Database.DMLOptions dmo = new Database.DMLOptions();
 dmo.assignmentRuleHeader.useDefaultRule = true;
 dmo.EmailHeader.triggerUserEmail = false; // optional
 dmo.EmailHeader.triggerAutoResponseEmail = false;

 Database.update(toUpdate, dmo);
 processed.addAll(ids);
 }
}

This approach is simple and reliable; it’s been recommended by community threads and how‑to articles (see https://sponge.io/how-to-re-run-salesforce-lead-assignment-rules-flows-apex/).

Implementation caveats: recursion, integrations, notifications, limits

• Recursion: Updating the inserted records will re‑enter triggers and can retrigger flows. The static Set/flag pattern shown prevents re-processing within the same transaction. Test carefully.
• Notifications & emails: Re-running assignment rules may trigger owner change emails or auto‑responses. Use Database.DMLOptions.EmailHeader flags if you need to suppress those.
• Order of execution: Your after‑save Flow or trigger update runs in the same transaction (unless you queue it). Other automations (Process Builder, Flows) that react on Owner changes will also run — plan for that.
• Bulk processing and limits: The extra Database.update counts as an additional DML; keep operations bulkified and avoid per‑record Apex calls. For very high volume, prefer Queueable/Batchable patterns.
• Integrations & inbound sources: API clients, web‑to‑lead forms, third‑party apps may create Leads without the assignment header. The Flow/Apex re‑run covers server‑side creates, but consider fixing external systems to set the assignment header where possible for immediate assignment.
• Testing: Add unit tests that create Leads in bulk, assert that OwnerId changes to the expected queue/user, and that recursion doesn’t occur. Test email suppression if you changed EmailHeader flags.
• Legacy claims: some older blog posts (e.g., 2012 era) state different behavior for hidden defaults — don’t rely on those without testing in your org and release.

For conceptual guidance on assignment rules and best practices see vendor and community resources: https://www.leandata.com/blog/lead-assignment-rules-salesforce/ and https://www.salesforceben.com/salesforce-lead-assignment-rules-best-practices-and-tricks/.

Quick checklist & troubleshooting steps

• [ ] Test your assignment rules manually: create a Lead with the UI checkbox visible and confirm expected owner/queue.
• [ ] Sandbox: implement the Flow + invocable Apex (or trigger) and test creates from UI, API, web forms and bulk loader.
• [ ] Watch debug logs: filter for assignmentRuleHeader usage and OwnerId changes.
• [ ] Check for duplicate emails — toggle EmailHeader flags if needed.
• [ ] Verify bulk behavior: create 200+ Leads in a test and confirm no governor limits are hit.
• [ ] If third‑party integrations create Leads, update them to pass the assignment header where feasible. If not feasible, rely on the server‑side re‑run as a safety net.
• [ ] Add unit tests that assert assignment rules ran and that recursion protection works.

If you see Leads still assigned to creators after implementing the above, check: (a) whether the Flow/trigger is active and deployed; (b) whether the invocable method received the expected Ids (Flow debug); © debug logs to confirm Database.update was called with assignmentRuleHeader.useDefaultRule = true.

Sources

• Stack Overflow — How do I make Auto Lead Assignment Checkbox Required (Salesforce)
• Salesforce Help — Set Up Assignment Rules
• Salesforce Help — Guidelines for Assignment Rules
• Automation Champion — Running Lead Assignment Rules From Salesforce Flow
• OpFocus — Configuring Active Assignment Rules in Salesforce
• Sponge — How to Re‑run Salesforce Lead Assignment Rules: Flows & Apex
• LeanData — Salesforce Lead Assignment Rules: A Quick Guide
• SalesforceBen — Lead Assignment Rules Best Practices and Tricks
• SimplySfdc — Assign Using Active Assignment Rule (older post — test behavior in your org)
• Salesforce IdeaExchange — Assignment Rules Run/Re‑Run by Flow (community request)

Conclusion

There’s no native UI switch to make the Lead Assignment checkbox required while hidden — the checkbox is an assignment‑rule DML header, not a persistent field. The reliable solution is automation: implement an after‑save record‑triggered Flow that calls an invocable Apex (or an Apex after‑insert handler) to re‑run Active Lead Assignment Rules with Database.DMLOptions.assignmentRuleHeader.useDefaultRule = true, add recursion guards, and test thoroughly across UI and integration entry points. This gives you consistent enforcement of lead assignment rules without letting users bypass them.