Salesforce Task Queue: Assign Tasks to a Queue and Notify Members

Yes, a Salesforce task can be owned by a queue. Task queues shipped in Spring '20, and the setup is the ordinary one: create a queue, add Task to its supported objects, add members. What surprises most admins is everything that does not come with it. No assignment rule will ever route a task, because assignment rules exist for leads and cases only. Queue email notifications do not fire on task assignment the way they do on a lead or a case. And a task owned by a queue drops out of the standard activity reports that filter on Assigned To. So the feature is real and useful, and it is a manual, Flow-driven construct rather than an automated routing destination. Here is exactly where each limit sits.

Can we assign a task to a queue in Salesforce?

You can, and for a while you could not, which is why this still comes up. Before Spring '20 a task needed a user owner, full stop, and the workaround was a dummy user account named something like "Support Queue" that a whole team shared a password to. That is gone. A queue can now hold task ownership the same way it holds a case or a lead, so a shared pile of follow-up work can sit somewhere neutral until a person picks it up.

The thing to hold onto is what a queue is underneath. It is stored as a Group record, which is why every queue ID starts with the 00G prefix while a user ID starts with 005. That single fact is what makes automation on task queues possible at all, because setting a task's OwnerId to a 00G value is how you assign it without a person being involved. It is also how you detect an unclaimed task later: a Flow or a report filter that tests whether OwnerId begins with 00G finds everything still sitting in a queue.

How to set up a Salesforce task queue

The setup takes about three minutes and has one step that people miss.

1. Create the queue. In Setup, search for Queues, click New, and give it a label and a queue name.
2. Add Task to the supported objects. This is the step that gets skipped. A queue only offers itself as an owner for the objects listed here, so a queue built for cases will not appear in the owner lookup on a task until Task is added to it.
3. Add members. 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 rather than needing an edit every time somebody joins or leaves.
4. Set the owner on a task. On the task record in Lightning, the Assigned To lookup lets you switch from People to Queues and pick it.

One quirk worth knowing before you roll it out: the queue option is not available everywhere a task can be created. Quick-create paths and some Lightning components only offer a user in the Assigned To field, so a task created from an activity timeline or a global action may need reassigning after the fact. Test the specific place your team creates tasks rather than assuming the record page behavior is universal.

Why no assignment rule will route a task to a queue

This is the real limitation and it is a structural one. Assignment rules in Salesforce exist for two objects: Lead and Case. There is no such thing as a task assignment rule, there is no setting that enables one, and no amount of configuration will produce one. So the pattern that works everywhere else, where an inbound record matches a rule entry and lands on a queue automatically, has no equivalent on the task object.

Workflow rules do not fill the gap either. A workflow field update cannot set a task's owner to a queue. What does work is Flow, or Apex, setting OwnerId directly to the queue's 00G ID. In a record-triggered Flow, the reliable way to get that ID is a Get Records on the Group object filtered by DeveloperName equals your queue's API name, storing the record's Id. Hardcoding the 00G string works in one org and breaks the moment you deploy to another, because queue IDs are not portable between orgs. If you would rather not spend a query on it, put the ID in a custom label per environment.

Salesforce task queue email notification: what actually fires

This is the second thing that catches teams, and the honest answer is that task queues are quieter than you expect. On a queue, two settings govern notification and they interact. If Queue Email is blank, every member is emailed individually regardless of the Send Email to Members checkbox. 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 single shared address instead.

That is the documented queue behavior. What it is tied to, though, is the events Salesforce treats as a queue assignment, and those center on lead and case assignment rules, workflow, and owner changes on those objects. Task ownership moving to a queue is not reliably one of them, which is why "why does my task queue not send email" is a recurring question with an unsatisfying answer, and why an open IdeaExchange request exists asking for exactly this. Do not design a process on the assumption that dropping a task into a queue pings anybody.

There is a second, separate limitation in the same area that is easy to conflate with it: an email alert cannot target a queue. Email alerts in Flow and in the old workflow engine send to users, to related contacts, to public groups, and to hardcoded addresses, and a queue is not on that list. The standard workaround is to create a public group containing the same people as the queue and point the email alert at the group. It means maintaining membership twice, which is annoying and is also what most orgs actually do. If you want a single shared inbox instead, put that address in the queue's Queue Email field and clear Send Email to Members, or use a hardcoded recipient on the alert.

One related trick from the queue toolbox: if you want a queue to send no email at all, entering an address that ends in .invalid is the accepted approach, because mail to a .invalid domain is discarded rather than bounced, so your org's sending reputation is not affected.

The reporting blind spot nobody warns you about

Standard activity reports in Salesforce are built around a user. Filter Tasks by Assigned To, group by owner, roll it up by role hierarchy, and the report answers "what is each person doing". A task owned by a queue has no person, so it falls out of that picture entirely. Teams discover this the week after adopting task queues, usually when a manager asks why open task volume dropped.

Two things help. First, report on Owner rather than reaching for a standard activity report, since the queue does appear in the Owner lookup and can be filtered on directly. Second, add a formula field or a report filter keyed on the 00G prefix so you can split "sitting in a queue" from "owned by a person" as a first-class dimension in your reporting, rather than treating unowned work as an absence. Unclaimed work you cannot see is the thing that actually costs you, and the fix is a saved report someone looks at, not a better queue.

What a task queue does not solve

Every limit above is a configuration detail. This last one is the design question, and it decides whether task queues help your team or quietly make things worse.

A queue is a waiting room. Nothing in it is assigned to anyone, no personal to-do list contains it, and no clock is running against a named person. What happens next is self-service, and self-service has a predictable shape in every team that has ever tried it: the quick items go first, the awkward ones age at the bottom of the list view, and whoever is most conscientious ends up carrying more than their share while the total looks evenly distributed because nobody is measuring who took what. Back-office teams live in this pattern already. A shared pile of work, several people who could take the next item, and no accountability for any single piece until somebody claims it. It is the same shape whether the queue holds Salesforce tasks, support tickets, or invoices waiting for approval.

An even queue does not produce an even day. If that matters for the work in question, the queue should be a staging point rather than the destination, and something should push each task to a named person shortly after it lands. Natively that means a scheduled Flow that finds tasks whose OwnerId still starts with 00G and assigns them, which you then have to keep fair yourself, because Flow has no rotation element and no view of who is already busy. Building round robin in Flow covers what that state management actually involves and which of the two common patterns holds up.

The alternative is to let a routing layer make the person decision. Assigner sits beside the Salesforce you already run and hands queued work to a named owner by round-robin assignment, weighted rotation, live workload, skill, or availability, using rules you control, at $12 per user per month. Every assignment records which rule fired and who else was eligible. It is a companion rather than a live two-way sync, and it is designed to help rather than to guarantee an outcome.

Task queue quick reference

• Available since: Spring '20. Add Task to the queue's supported objects or it will not appear in the Assigned To lookup.
• Assignment rules: leads and cases only. None will ever touch a task.
• Automation: Flow or Apex setting OwnerId to the queue's 00G ID. Look it up on the Group object by DeveloperName rather than hardcoding.
• Notifications: do not assume a task landing in a queue emails anyone. Email alerts cannot target a queue at all; use a public group with the same members.
• Reporting: report on Owner, not the standard activity Assigned To view, or queue-owned tasks disappear.
• The real question: who picks it up, and when. A queue does not answer that.

If you are designing queue routing more broadly rather than just for tasks, Salesforce queue assignment covers which objects can be owned by a queue at all, the four routes records take to get onto one, and the membership and notification settings in full. For getting a record onto a queue from a Flow, step by element, see assigning a record to a queue in Salesforce Flow.