---
title: "Case assignment rules: order, criteria, and the silent no-match"
url: "https://trailassembly.com/case-assignment-rules/"
topic: "Admin and Permissions"
published: "2026-09-12T05:20:56+00:00"
updated: "2026-10-06T13:53:22+00:00"
---

# Case assignment rules: order, criteria, and the silent no-match

**Straight answer:** assignment rules evaluate entry by entry, top to bottom, and stop at the first match. Only one rule per object can be active at a time, so “rules” plural means entries within one rule. The silent failure everyone hits is a case that matches nothing, which is assigned to the Default Case Owner and looks like it went missing.

## How the evaluation actually works

One active rule. Inside it, an ordered list of entries. Each entry has criteria and an assignee. The first entry whose criteria match wins, the case is assigned, and nothing further is evaluated.

So order is the design. An entry with broad criteria placed second makes every entry below it unreachable, and nothing in the interface warns you. When an entry appears to do nothing, check what is above it before checking its criteria.

## The default owner, which is where cases go to hide

A case matching no entry is assigned to the Default Case Owner, set in Support Settings. If nobody configured it, that is whoever created the case or the org’s default, and the case sits in a queue nobody monitors.

The fix is a deliberate catch-all as the final entry, with criteria that always match, assigning to a triage queue that a person actually works. Then “no rule matched” becomes visible rather than silent.

## Rules do not run unless something asks them to

This catches every integration. Assignment rules fire when:

- A case is created through the UI with “Assign using active assignment rule” checked, and that checkbox’s default comes from the page layout

- Web-to-Case and [Email-to-Case](https://trailassembly.com/email-to-case-threading/), always

- An API call that explicitly sets the `AssignmentRuleHeader`

- Apex that sets `DmlOptions.assignmentRuleHeader.useDefaultRule = true`

They do not fire on an ordinary API insert, an ordinary Apex insert, or a flow Create Records element without the “use assignment rules” option. A case created by an integration and left unassigned is almost always this.

```apex
Database.DMLOptions opts = new Database.DMLOptions();
opts.assignmentRuleHeader.useDefaultRule = true;
Case c = new Case(Subject = 'From integration');
c.setOptions(opts);
insert c;
```

## Where assignment sits in the save order

Assignment rules run after before-triggers and validation rules, and after the record is saved but before after-triggers see the final owner. Two consequences worth knowing:

A before-trigger setting `OwnerId` is overwritten by the assignment rule. If you want code to win, the code has to run after, or the rule needs criteria that exclude those cases.

An after-trigger sees the assigned owner, which is why owner-based notifications belong there rather than in a before-trigger.

The full sequence is in [the order of execution](https://trailassembly.com/order-of-execution/), and assignment is one of the steps people forget is in it.

## Criteria that do not do what you expect

**Blank field comparisons.** “Field not equal to X” matches records where the field is blank, which is usually not what was meant. Add an explicit “not equal to blank” condition.

**Picklist ordering.** Greater-than and less-than on a picklist compare by the order in the picklist definition, not alphabetically. Reordering the picklist silently changes rule behaviour.

**Formula criteria.** An entry can use a formula instead of the field grid, which handles everything the grid cannot: cross-object references, OR logic across different fields, and functions. Where an entry is becoming a maze of rows, a formula is usually shorter and easier to read.

## Queues versus users

Assigning to a queue is nearly always better than assigning to a person. A named individual goes on holiday, changes team, or leaves, and the rule keeps assigning to them. A queue survives all three, and queue membership is a permission change rather than a metadata deployment.

Queue assignment also avoids the ownership concentration that leads to [ownership skew](https://trailassembly.com/salesforce-ownership-skew/) when a routing user accumulates records.

## Testing them

There is no simulator. The workable approach is a sandbox with the same rule, a set of cases covering each entry including the catch-all, and a check of the resulting owner. Write the expected owner per test case down first, because reading the rule and reading the result at the same time is how people convince themselves a broken rule works.

## Frequently asked

**Can I have more than one active rule?** No, one per object. Multiple rules can exist, one is active.

**Does the rule send an email?** Each entry has an optional [email template](https://trailassembly.com/salesforce-email-templates/), and it sends to the new owner. Leave it blank and the assignment is silent.

**Do assignment rules apply to Leads too?** Yes, with the same mechanics, the same single-active-rule constraint and the same integration blind spot.

---

Source: https://trailassembly.com/case-assignment-rules/
Trail Assembly — independent Salesforce write-ups.