Salesforce Queue Assignment: Queue Assignment Rules for Cases, Leads, and Custom Objects

What is a queue in Salesforce, and what is it actually made of?

A queue behaves like a user that happens to be a group of people. Set the owner of a record to a queue and the record has no individual owner: it belongs to the queue, and every member can see it and take it. Underneath, a queue is stored as a Group record, which is why its ID always begins with the 00G prefix while a user ID begins with 005. That detail sounds like trivia and it is the single most useful thing to know about queues, because it is what makes automation possible. A record-triggered Flow can test whether OwnerId starts with 00G to detect "this record is sitting on a queue and nobody has claimed it", and that one condition is the foundation of every serious queue design. Creating a queue also creates a list view automatically, which is how members find the records waiting for them, and queue ownership doubles as a sharing mechanism: membership grants visibility of everything the queue owns, without writing a sharing rule. The limitation that surprises people is that queue ownership is not universal. Cases, leads, tasks, contact requests, orders, service contracts, knowledge article versions, and custom objects can be owned by a queue. Accounts and opportunities cannot. If your routing design assumes an opportunity can wait on a queue until someone claims it, that design needs a different shape, usually a custom object or a task that carries the queue while the opportunity keeps a placeholder owner.

How do you assign a record to a queue in Salesforce? The four routes, and which objects get which

There are exactly four ways a record ends up owned by a queue, and the object you are working on decides which of them are open to you. The first is an assignment rule, and this is the one with the sharp restriction: assignment rules exist for leads and cases only. One rule can be active at a time per object, its entries are evaluated in sort order from 1 upward, the first match wins, and the action can set the owner to a user or a queue. For most support and inbound sales designs, pointing rule entries at queues rather than named individuals is the right call, because a named individual bakes in an availability assumption that is false most Tuesdays. The second is a manual owner change, which works on every queue-enabled object and is what agents use to hand a record back. The third is Flow, and this is where custom objects, tasks, and orders live, since no assignment rule will ever touch them. You set the record's OwnerId to the queue's 00G ID, which you get either from a Get Records on the Group object filtered by DeveloperName, or from a custom label holding the ID so it survives a deployment between orgs. Assigning a record to a queue in Salesforce Flow walks that build element by element, including the before-save versus after-save decision. The fourth is Apex or the API, where you set OwnerId directly and, on leads and cases, decide separately whether to attach an assignment rule header so the native rule also runs. That last point catches integrations constantly: records created by an integration keep the running user as owner while manually created records route correctly, and the rule gets blamed for a problem that lives in the calling code.

Queue email and Send Email to Members: the setting that decides who hears about the record

When you create a queue, two fields control notifications and they combine in a way that is not obvious from either one on its own. Queue Email is a single address, meant for a shared inbox or a distribution list. Send Email to Members is a checkbox. The behaviour is this: if Queue Email is blank, every queue member is emailed individually, regardless of whether the checkbox is ticked. If Queue Email is filled in and the checkbox is ticked, every member is emailed individually as well. Only when Queue Email is filled in and the checkbox is cleared does the notification go to that single shared address instead. So the default state, a blank Queue Email, quietly means everybody gets everything, and on a busy lead queue that is how a team learns to filter Salesforce notifications into a folder they never open. Decide deliberately: a shared support inbox that somebody triages belongs in Queue Email with the checkbox cleared, and a small team that genuinely wants individual pings belongs with the checkbox ticked. If you want no email at all, the accepted trick is to enter an address ending in .invalid, because mail to a .invalid domain is discarded by the Salesforce email agent rather than bouncing and hurting your org's deliverability. Worth knowing alongside this: a queue is not the same thing as a public group. A public group is purely a sharing and membership construct and cannot own records, so email alerts and sharing rules often target a public group while ownership targets a queue, and many orgs end up maintaining both with the same members in each.

Queue members, role hierarchy, and why the right people cannot see the queue

Members can be added four ways, and the difference matters more than it looks. You can add individual users, a role, a role and subordinates, or a public group. Adding a role rather than a list of users is what stops queue membership rotting every time somebody joins the team, and it is the single best maintenance decision available here, because the queue then inherits whoever holds that role today. There is one behaviour that regularly confuses people during an audit: users above the queue members in the role hierarchy can also take ownership of records in the queue, even though they were never added as members. That is by design, it follows from how ownership and the hierarchy interact, and it means a manager appearing in your assignment history is not evidence that somebody broke the membership list. The opposite problem is the common one. A user is in the queue, opens the list view, and sees nothing. Almost always this is object-level or field-level access rather than queue membership: profile permissions on the object, the list view being filtered to something narrower than expected, or the user simply looking at a different list view with the same name. Check the profile before you touch the queue. And when a validation rule exists that requires a real user in some field, members can find themselves unable to complete work while the queue still owns the record, so the record has to be reassigned to a person before it can move at all. That is not a bug, but it is worth knowing before you write the validation rule.

The pull problem: a queue is a waiting room, not an assignment

Everything above is configuration. This last part is the design question, and it is the one that decides whether queue-based routing works for your team. A record on a queue has no owner in any meaningful sense. Nobody is accountable for it, no personal to-do list contains it, and if your SLA clock started at creation then it is running while the record waits for a volunteer. What happens next is self-service, and self-service has a predictable shape: the fastest agents take the most work, the interesting or easy records get cherry-picked, and the difficult ones age at the bottom of the list view until somebody escalates. An even queue does not produce an even day. Salesforce's own answer to this gap is Omni-Channel, which pushes queued work to agents with capacity rather than waiting for them to pull, and it is a good answer if you are on a plan that includes it and your people work in the Service Console. Note Salesforce's own guidance 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 pattern that works is rules pick the queue, something else picks the person. The other route to the same outcome, and the one that works on any edition and on any object, is to route off the queue automatically: watch for OwnerId starting with 00G and hand the record to a named person by rotation, by workload, or by skill. That is exactly what Assigner does beside the Salesforce you already run. One engine covers Salesforce lead routing and Salesforce case assignment rules with round-robin assignment, workload balancing, skills-based routing, and availability routing, priced openly at $12 per user per month, with the rule and the candidate list recorded on every assignment. Our comparison against native Salesforce assignment rules sets out where staying native clearly wins, because for genuinely criteria-shaped routing it often does. It is a companion rather than a live two-way sync, and it is built to help rather than to guarantee an outcome.

What is a queue in Salesforce?

A queue is a shared ownership bucket that can own records instead of a user owning them. Every queue member can see the records the queue owns and take one by changing the owner to themselves. Underneath, a queue is stored as a Group record, so its ID always begins with the 00G prefix, and creating a queue automatically creates a list view for it.

Which objects support queues in Salesforce?

Queues can own cases, leads, tasks, contact requests, orders, service contracts, knowledge article versions, and custom objects. Accounts and opportunities cannot be owned by a queue. Native assignment rules are narrower still: they exist for leads and cases only, so routing into a queue on any other object has to be done with Flow, Apex, or a manual owner change.

How do I assign a record to a queue in Salesforce?

There are four routes. An active assignment rule can set the owner to a queue, but only on leads and cases. Anyone with edit access can change the owner field to the queue manually. A Flow can set OwnerId to the queue ID, which begins with 00G. Apex or an API insert can set OwnerId directly, optionally attaching an assignment rule header on leads and cases.

How do I create a case queue in Salesforce?

In Setup, search for Queues and click New. Give the queue a label and a queue name, set the Queue Email and Send Email to Members options, add Case to the list of supported objects, then add members as users, roles, roles and subordinates, or public groups. Save, then point a case assignment rule entry or a Flow at the new queue so records reach it.

Who receives the email when a record is added to a queue?

It depends on two settings together. If Queue Email is blank, every member is emailed individually whether or not Send Email to Members is ticked. If Queue Email is filled in and the checkbox is ticked, members are still emailed individually. Only a filled-in Queue Email with the checkbox cleared sends to that one shared address instead.

What is the difference between a queue and a public group in Salesforce?

A queue can own records, and a public group cannot. Public groups are a sharing and membership construct used in sharing rules, list view visibility, and email alerts. Queues add record ownership on top of membership. Many orgs maintain both with the same members, using the group for sharing and alerts and the queue for holding unclaimed records.

Who can be a queue member in Salesforce?

Members can be added as individual users, a role, a role and subordinates, or a public group. Adding a role rather than a list of names is the lower maintenance choice, because the queue then follows whoever holds that role. Separately, users above the members in the role hierarchy can take ownership of queue records even though they are not listed as members.

Can you set up queue assignment rules for custom objects in Salesforce?

Not natively. Assignment rules in Salesforce exist for leads and cases only, so no rule will route a custom object record into a queue. A custom object can still be owned by a queue, so the standard approach is a record-triggered Flow that sets OwnerId to the queue ID. That ID begins with 00G and is usually stored in a custom label so it survives deployment between orgs.

Does Salesforce have round robin assignment within a queue?

No. A queue holds records until a member claims one, and nothing rotates them. The common workaround is an auto-number field plus a MOD formula that assigns records to buckets, with one assignment rule entry per bucket. It splits by count rather than workload, the bucket count is hardcoded into the formula, and absent or deactivated users keep drawing their share.

What is the difference between a case team and a queue in Salesforce?

A case team is a set of people who collaborate on a single case, each with a role and a defined level of access, while the case still has one owner. A queue is an ownership construct that holds cases nobody owns yet. Use a queue for unclaimed work waiting to be picked up, and a case team for named collaborators on work that already has an owner.

How do I find which records are assigned to a queue?

Every queue creates a list view on the objects it supports, so the fastest check is to open that list view on the object. For a broader answer, filter any list view or report by Owner and choose the queue, since the queue appears in the owner lookup alongside users. In SOQL, query the Group object with Type equals Queue to get the queue ID, then filter records on OwnerId.