Salesforce Case Assignment Rules: Case Routing, Queues, and Round Robin Case Assignment

How do case assignment rules work in Salesforce?

A case assignment rule is a container, and the logic lives in the rule entries inside it. Each entry has a sort order, a set of criteria or a formula, and an action: set the owner to a user or a queue, and optionally send an email template. When a case is created, Salesforce walks the entries in sort order starting at 1 and stops at the first one that matches. That is the single most important behaviour to internalize, because it means an entry near the top with loose criteria will swallow cases you meant for an entry lower down, and no error is raised when that happens. Two limits shape how far this can be pushed. Only one case assignment rule can be active at a time in an org, so all of your routing has to fit inside one rule. That rule can hold up to 3,000 rule entries, which sounds generous until routing depends on product multiplied by region multiplied by support tier, at which point the entry count grows faster than anyone expects and the ordering becomes the actual maintenance burden. The action can point at a queue rather than a user, and for most support teams it should. Assigning a case to a named individual at creation time bakes in an availability assumption that was true when the rule was written and is false most Tuesdays. Assigning to a queue keeps the case visible to a group, which is why the standard pattern is rules into queues, then something else to get the case from the queue onto a person.

The page layout checkbox that decides whether your rules run at all

This is the cause behind more "our case assignment rules stopped working" tickets than every other cause combined, and it is not in the rule. Open Setup, then Object Manager, then Case, then Case Page Layouts, open a layout and click Layout Properties. Under Case Assignment Checkbox there are two independent options, Default and Show on edit page, and the combination you pick determines the behaviour completely. With Default selected and Show on edit page cleared, the rules always run and no checkbox appears in the interface, so nobody can turn them off. With both selected, the checkbox appears and is pre-ticked, so rules run unless somebody deliberately unticks it. With only Show on edit page selected, the checkbox appears unticked, which means rules never run on a manual save unless the person saving remembers to tick a box they have no reason to notice. The reason this is so hard to diagnose is that it is a property of an individual page layout. Two teams in the same org, on the same active rule, can get opposite behaviour because their profiles resolve to different case layouts. Before you touch a rule entry, check the layout properties on every layout in play. If you want rules to run without exception on manual saves, select Default and clear Show on edit page. If your agents legitimately need to bypass routing sometimes, show the checkbox and accept that it will occasionally be unticked. What you should not do is leave the third combination in place by accident, which is where most orgs are when they start investigating.

Round robin case assignment in Salesforce, and why the usual workaround decays

Salesforce has no native round robin for cases. The workaround is well known and worth understanding before you commit to it, because its failure modes are what eventually push teams to a routing layer. You create an auto-number field on the case so every new case gets a sequential number, then a formula field along the lines of 1 + MOD(VALUE(Case_Number_Auto__c), 5) to turn that sequence into a bucket from 1 to 5, then one rule entry per bucket pointing at one agent. New cases cycle through the buckets and the split looks even. It works, and then it decays in four predictable ways. The bucket count is hardcoded into the formula, so adding or removing an agent means editing the formula and re-pointing every entry, and the rotation reshuffles for everyone rather than absorbing the change. A deactivated agent, or one on vacation, keeps drawing their share, and the cases sit untouched until somebody notices. The auto-number is stamped at insert, so nothing re-rotates when a case is updated or reopened. Most importantly it distributes count, not work: five easy password resets and five multi-day escalations are the same number to a modulo, so an even count produces a wildly uneven day. That last point is the honest argument for a dedicated layer. Round-robin assignment that keeps real rotation state does not care how many agents there are this week, and workload balancing distributes open effort rather than record counts. If you want the mechanics of the native approach in more depth, round robin lead assignment in Salesforce walks the same pattern on the lead side.

Queues, the default case owner, and where cases quietly go to die

Every routing design needs an answer for the case that matches nothing, and Salesforce gives you one whether you design it or not. In Setup, under Support Settings, the Default Case Owner is the user or queue that receives anything the active rule did not match, and Notify Default Case Owner controls whether they hear about it. Left at a named individual, which is a common default, unmatched cases accumulate in one person's ownership where the rest of the team cannot see them. The fix is small and worth doing today: point the default case owner at a catch-all queue that a real human reviews, and add a final rule entry with criteria loose enough to catch everything, so the fallthrough is deliberate rather than accidental. Queues themselves are the right destination for most rule entries, but a queue is a waiting room and not an assignment. A case sitting in a queue has no owner in any meaningful sense, and what happens next is self-service: the fastest agents take the most work, the interesting cases get cherry-picked, and whoever started last week gets what is left. Omni-Channel is Salesforce's own answer to that gap and it is a good one, pushing queued work to agents with capacity, though it needs Service Cloud, the Service Console, and per-channel capacity configuration. Worth knowing before you combine them: Salesforce's own guidance is to avoid running case assignment rules alongside an Omni-Channel flow for Email-to-Case, because the two will fight over the same decision. The workable pattern is rules to pick the queue, Omni-Channel or an external engine to pick the person.

When native case assignment rules are enough, and when they are not

They are enough more often than vendors like us admit. If your routing is genuinely criteria-shaped, a case with product equals Billing goes to the Billing queue, and your team pulls from queues without complaint, then one active rule with a handful of well-ordered entries is the correct answer and adding a tool would be waste. The honest boundary is the point where the decision stops being about the case and starts being about the people. Native rules read fields on the case, the account, and the contact. They cannot read who is online, who is at capacity, who has the certification this case needs, who is on shift in this timezone, or who took the last one. Every attempt to encode those in criteria ends as the auto-number workaround above plus a growing pile of entries that nobody dares reorder. That is the gap Assigner fills, and it fills it beside Salesforce rather than instead of it. One engine handles support ticket routing, sales lead routing, and ops tasks with skills-based routing and availability routing included, priced openly at $12 per user per month, with the rule and the candidate list shown on every assignment. Our comparison against native Salesforce assignment rules sets out where staying native clearly wins. It is a companion rather than a live two-way sync, and it is built to help rather than to guarantee an outcome.

What are case assignment rules in Salesforce?

Case assignment rules are ordered criteria that set the owner of a case, either a user or a queue, when the case is created. Only one case assignment rule can be active in an org at a time, and it can hold up to 3,000 rule entries. Entries are evaluated by sort order from 1 upward, and the first one that matches wins and stops the evaluation.

When do case assignment rules run in Salesforce?

They run automatically for cases created through Web-to-Case and Email-to-Case. On a manual save they run only if the Case Assignment Checkbox is set to default on for that page layout. Apex, API, and bulk inserts skip them unless the call attaches Database.DMLOptions with an assignment rule header, and record-triggered Flow has no standard option to run them.

What is the case assignment rules limit in Salesforce?

One case assignment rule can be active at any time, and that rule can contain up to 3,000 rule entries. The practical limit arrives well before 3,000, because entries are evaluated in sort order and every new entry has to be placed correctly relative to the others. Ordering, not the entry cap, is what makes large rules hard to maintain.

How do you trigger case assignment rules in Salesforce from Apex?

Build a Database.DMLOptions object, set assignmentRuleHeader.assignmentRuleId to the rule ID or set useDefaultRule to true, then call setOptions on the case before inserting it. Without this, records created in Apex keep the running user as owner. If you set the assignment rule header but not the email header, the case is assigned correctly and the new owner receives no notification.

Do Salesforce case assignment rules run on update?

Not on their own. A rule fires on creation, and on an update it runs only if the assignment checkbox is visible on the layout and the person editing ticks it during that save. Changing a case type or priority after creation does not re-route the case. If you need reassignment when a field changes, that has to be built with Flow, Apex, or a routing layer that watches the record.

How do you bypass case assignment rules in Salesforce?

Show the Case Assignment Checkbox on the page layout and leave it unticked on the save you want to bypass. In Apex or the API, simply omit the assignment rule header, since rules do not run there by default. Both approaches are per-save rather than per-user, so if you need a permanent exemption for a team it is cleaner to give them a page layout without the checkbox defaulted on.

Does Salesforce have round robin case assignment?

Not natively. The standard workaround is an auto-number field plus a formula field using MOD to turn the sequence into a bucket, with one rule entry per bucket. It splits cases evenly by count, but the bucket count is hardcoded, deactivated or absent agents keep drawing their share, and it distributes records rather than workload, so an even count still produces uneven days.

Why are case assignment rules not working for one email address only?

Check the Email-to-Case routing address. Each routing address has its own Case Owner field, and when a user or queue is set there it overrides both the active assignment rule and the Default Case Owner for mail arriving at that address. Every other inbox obeys the rules normally, which makes this look like a rule problem when it is a routing address setting.

What happens to a case that matches no assignment rule entry?

It goes to the Default Case Owner configured in Support Settings, and the Notify Default Case Owner setting decides whether that person is told. Pointing the default at a named individual hides unmatched cases in one person's ownership. Point it at a catch-all queue somebody reviews, and add a deliberately loose final rule entry so the fallthrough is designed rather than accidental.

How do you test case assignment rules in Salesforce?

Create test cases through every entry point you actually use, not just the Lightning form, because the entry point decides whether rules run at all. Save one manually, submit one through Web-to-Case, send one to each Email-to-Case address, and insert one through the API. Then check the owner and the case history on each. Differences between those four results tell you which setting is responsible.