Salesforce Case Assignment Rules Not Working: Causes and Fixes

Salesforce case assignment rules almost never fail because the rule logic is wrong. They fail because the rule was never invoked. The four causes that account for most of it: the "Assign using active assignment rules" checkbox was not checked, the case was created by Apex, an API call, a Flow, or Experience Cloud, which do not run assignment rules unless you explicitly tell them to; a second rule is the active one, because only one case assignment rule can be active at a time; or an earlier entry in the sort order already matched and evaluation stopped. Check invocation before you touch a single criterion.

The reason this wastes so much time is that a rule that never runs looks exactly like a rule with bad criteria. Both produce a case sitting on the default owner. Admins reflexively open the rule entries and start rewriting conditions, which is the one place the problem usually is not. Work through the causes in the order below and most of these resolve in a few minutes.

Why are my Salesforce case assignment rules not working?

Start with whether the rule was invoked at all. Salesforce runs case assignment rules only when something asks it to, and most of the ways a case gets created do not ask by default. Below are the causes ranked by how often they turn out to be the answer.

Common causes of case assignment rules not firing

The assignment checkbox is the single biggest cause

When a user creates or edits a case in the Salesforce UI, assignment rules run only if "Assign using active assignment rules" is selected. If that checkbox is not on the page layout, or it is on the layout but unchecked by default, every case a user saves keeps whatever owner it had. The rule is active, correct, and simply not asked to run.

The fix is a layout setting rather than a rule change. In the page layout properties there is a Case Assignment Checkbox section with two options. Enable the Default checkbox so the box is pre-selected, and disable "Show on edit page" so users cannot turn it off. That combination forces assignment on every save and removes the most common variable in the whole system: whether a particular rep remembered to tick a box.

One caution before you do it globally. If any part of your process depends on a user deliberately keeping a case, hiding the checkbox removes that escape hatch. In practice most teams find the escape hatch was never intentional.

Salesforce case assignment rules not working from Apex or the API

This is the version that survives testing. An admin creates a case by hand, the rule fires, everyone signs off, and then every case from the web form, the integration, or the nightly job lands on the default owner. Assignment rules do not run automatically on records inserted through Apex or the API. You have to attach an assignment rule header to the DML operation.

In Apex that means building a Database.DMLOptions instance, setting the assignment rule on it, and applying it to the record before insert. You can either point at a specific rule with dmlOpts.assignmentRuleHeader.assignmentRuleId, or set useDefaultRule to true to run whichever case assignment rule is currently active. Then call setOptions on the case instance before the insert. Without that, the insert is invisible to the assignment engine.

There is a second-order gotcha worth knowing. If you specify the assignment rule header but not the email header, records are assigned but the new owners get no assignment notification. Teams often discover this weeks later when a queue owner mentions they stopped receiving anything, and the natural assumption is that routing broke, when in fact only the notification did.

Can Flow run case assignment rules?

Not natively on Case, and this catches out teams migrating from Process Builder and Workflow. When a Flow creates a case record, there is no standard option to run the active case assignment rules, so the case is created with whatever owner the Flow set and the rules never see it. Lead has had a cleaner path here for longer, which is why the advice you find often does not transfer.

Two workarounds hold up. The first is an invocable Apex method that performs the insert or update with the assignment rule header attached, called from the Flow. That keeps the routing logic in Salesforce assignment rules where admins can read it, and puts only the plumbing in code. The second applies specifically to Email-to-Case: route with an Omni-Channel flow rather than assignment rules, and then deliberately keep case assignment rules out of the picture so the two are not fighting over the same records. Salesforce guidance is explicit that you should pick one. We walk through the queue-assignment side of this in Salesforce Flow assign to queue, and the Omni-Channel failure modes in Salesforce Omni-Channel not assigning work.

Case assignment rules not working in a community or Experience Cloud site

Cases created by a community user go through the same rule as everything else, so when they behave differently the cause is nearly always the invocation path rather than the rule. A case submitted through a custom Lightning component, a Flow-based intake screen, or an Apex controller is an Apex insert, and it needs the assignment rule header exactly like any other integration. A case submitted through the standard case creation action inherits the normal checkbox behavior.

Web-to-Case is the exception that confuses people, because it does run the active assignment rule and falls back to the default case owner when nothing matches. So a site with a Web-to-Case form and a custom component can have two intake paths where one routes correctly and the other never has, and nobody notices until volume shifts between them. Worth auditing both paths separately rather than assuming the entry point does not matter.

Why case assignment rules do not reassign an existing owner

Assignment rules set an owner. They are not designed to take one away. If something earlier in the save has already populated OwnerId, whether that is a before-trigger, a field default, a template, or an integration passing an owner explicitly, the rule has nothing to do. This is the same behavior pattern that trips people up in other platforms, and it is the reason "the rule looks right and does nothing" is such a common report.

It also explains a lot of confusion around updates. A rule entry can be configured to run on create only, or on create and edit. If yours is create-only, editing a case will never re-route it no matter what changes. And even when a rule is set to run on edit, the checkbox still has to be selected on that save, which means an update from an integration hits both problems at once.

The general principle is one worth applying beyond assignment rules: pick a single authoritative mechanism per object. When triggers, flows, assignment rules, and Omni-Channel can all write OwnerId, the resulting behavior is only predictable if exactly one of them owns the decision. The same discipline applies as teams add AI triage on top, where it is worth putting explicit guardrails on what an automated agent is allowed to touch and reassign before it starts writing to records your rules also manage.

Only one case assignment rule can be active

You can create as many case assignment rules as you like, a standard one and a holiday one and a pilot one, but exactly one is active at any moment. Editing the wrong one is a genuinely common waste of an afternoon. Open Setup, go to Case Assignment Rules, and confirm which record carries the Active flag before you change anything.

Inside the active rule, the entries are what actually match. Each entry has a Sort Order, and Salesforce evaluates them from 1 upward, applying the first entry whose criteria match and stopping there. Later matching entries never run. Two habits follow. Order entries from most specific to most general, because a broad entry near the top will swallow the cases a narrower entry further down was written to catch. And leave gaps in the numbering so inserting a new entry later does not mean renumbering everything. A single rule supports up to 3,000 entries, which is far more headroom than most teams need and, past a few dozen, far more than anyone can reason about.

Where case assignment rules run in the order of execution

Assignment rules execute after Apex before-triggers and before workflow rules. That ordering has one practical consequence worth internalizing: anything a before-trigger does to OwnerId happens first and wins, because the rule will not overwrite a populated owner. If you need a trigger to prepare data that your rule criteria depend on, that works fine. If you need a trigger to decide the owner, you do not need the assignment rule at all, and running both is how instances end up with routing nobody can explain.

The sibling article on the Lead side covers the same ordering questions with the differences that matter, since Salesforce lead assignment rules not working has its own set of causes around lead conversion and web-to-lead.

A checklist that resolves most cases

Run these in order. Stop when the behavior changes.

One. Confirm which case assignment rule is Active. Not which one you edited most recently.

Two. Create a case manually with the assignment checkbox visibly checked. If it routes, your rule is fine and the problem is invocation on some other path.

Three. List every way a case gets created in your org: UI, Web-to-Case, Email-to-Case, Experience Cloud, Flow, Apex, integrations. Test each separately. They do not behave the same.

Four. Check whether anything sets OwnerId before the rule runs. A populated owner means the rule is skipped, not overridden.

Five. Read the Sort Order top down and find the first entry that matches your test case. That is the entry running, whether or not it is the one you meant.

When the rule is fine and the routing still is not

There is a point past which none of this is a bug. Case assignment rules match criteria to a queue or a user, and that is the whole feature. They do not know who is at capacity, who is on shift, who has the skill the case needs, or who has already taken four escalations this morning. So teams build the missing half themselves: a trigger for rotation, a scheduled job to rebalance, a report someone checks on Mondays, and a growing pile of automation that only one person understands.

That is a different problem from a rule not firing, and it does not get better by adding entries. A routing layer beside Salesforce keeps Salesforce as the system of record and handles the assignment decision with rules a support manager can edit directly, including round-robin assignment weighted by current workload and filtered by who is actually available. Every assignment names the rule that produced it, so "why did this come to me" takes a glance rather than a code review. Our Salesforce assignment rules comparison covers what native rules do well and where they stop, and Salesforce case routing goes deeper on the case side specifically. Assigner is a companion to Salesforce rather than a replacement or a live two-way sync, it starts at $12 per user per month, and it is built to assist your triage rather than to guarantee an outcome.