Salesforce Flow Assign to Queue: Leads, Cases, and Tasks

To assign a record to a queue in Salesforce Flow, set the record OwnerId to the queue ID. Queues are stored as Group records with Type equal to Queue, so the reliable pattern is a Get Records element that finds the Group by DeveloperName, followed by an Update Records or Create Records element that sets OwnerId to that group Id. This works for Leads, Cases, and Tasks, as long as the queue is configured to support that object. Hardcoding the 18-character queue ID also works, but it breaks the moment you deploy to another org, so look it up instead.

Why OwnerId is the whole trick

People look for an "assign to queue" action in Flow and do not find one, because Salesforce does not model queue assignment as a separate operation. Ownership of a Lead, Case, or Task can point at either a User or a Group of type Queue, and the OwnerId field accepts both. So assigning to a queue is just setting an owner. Once that clicks, the rest of the build is plumbing: get the right Id, then write it.

The Group object is where queues live. Every queue you create in Setup produces a Group record with Type = 'Queue', a Name (the label you see in the UI) and a DeveloperName (the API name). DeveloperName is the value you want to filter on, because labels get renamed by people who do not know a Flow depends on them.

Build it step by step

1. Create the queue first. In Setup, go to Queues, create the queue, add the objects it should support (Lead, Case, Task, or custom), and add members. A queue that does not list the object cannot own that object record.
2. Start a record-triggered Flow. Choose the object, and pick "A record is created" or "A record is created or updated" depending on when routing should happen. For assignment on create, "Fast Field Updates" (before-save) is the cheapest option and lets you set OwnerId without a separate Update element.
3. Set entry conditions. Be specific. Something like Country equals United States AND LeadSource equals Web. Tight entry conditions are what stop the Flow re-firing on every later edit.
4. Get the queue Id. Add a Get Records element on the Group object, filter where Type equals Queue AND DeveloperName equals your queue API name, and store the first record. Store only the Id field to keep it lean.
5. Set the owner. In a before-save Flow, assign the retrieved Id straight into the record OwnerId. In an after-save Flow, use Update Records on the triggering record and set OwnerId to the retrieved Id.
6. Activate and test. Create a test record that matches the entry conditions and confirm it lands in the queue list view. Then create one that does not match and confirm nothing moves.

Before-save or after-save

Record-triggered Flows run in two places, and the choice matters more for assignment than for most automations.

If all you are doing is putting the record in a queue, use before-save. It avoids a second save and keeps the record from bouncing through other automations twice.

Leads, Cases, and Tasks each behave a little differently

Leads. The gotcha is interaction with lead assignment rules. If your active assignment rule also touches the same records, you now have two systems fighting over the owner, and which one wins depends on the Salesforce order of execution. Pick one path per segment of leads and use entry conditions to keep them apart.

Cases. Same story with case assignment rules, plus Omni-Channel. If Omni-Channel is routing from a queue, a Flow that also sets the owner can pull the case out from under the router. The usual clean split is: Flow decides which queue, Omni-Channel decides which agent inside it, which is the model Salesforce Omni-Channel routing is built around.

Tasks. Task queues are supported, but the queue has to list Task as a supported object, and a task owned by a queue does not appear in an individual to-do list until somebody accepts it. That is fine for a shared work pool and bad for anything with a deadline nobody owns.

Common problems and what causes them

• "Invalid owner" or an insert error. The queue does not support that object. Add the object to the queue in Setup.
• Get Records returns nothing. Almost always a DeveloperName typo, or filtering on Name instead of DeveloperName after someone renamed the queue label.
• The Flow keeps re-firing. Your entry conditions match records the Flow itself just changed. Add a condition such as OwnerId does not equal the queue, or use the "Only when a record is updated to meet the condition requirements" option.
• Records land in the queue and never move. That is queues working as designed. Somebody has to accept them. If nobody does, you need either a person-level assignment or a rule that escalates aging records out of the queue.
• It works in sandbox and fails in production. A hardcoded queue Id. Ids differ per org, which is exactly why the Get Records lookup is worth the extra element.

That last category, automation that silently stops doing its job, is the expensive one. A Flow that quietly stops assigning does not throw an error anyone sees; the queue just gets quiet and the backlog grows somewhere else. If these records feed a warehouse or reporting layer, monitoring the freshness and volume of the tables they land in will surface a stalled routing Flow days before someone notices in the UI.

Flow versus assignment rules versus a routing layer

Flow is the most flexible native option: it can look up related records, branch on anything, and call Apex. What it cannot do is re-run lead or case assignment rules on its own, which needs an invocable Apex action, and it has no concept of who is busy or who is next in rotation. If you want round-robin or workload balancing in Flow, you are writing and maintaining that state yourself, usually in a custom object or a counter field, and it becomes somebody job to keep it correct.

That is the point where a routing layer beside Salesforce is cheaper than the build. Assigner distributes leads, tickets, and ops tasks by round-robin, weighted round-robin, skill, open workload, priority, and availability, respects working hours, and shows the rule behind every assignment, without a queue that people have to remember to check. See Salesforce lead routing beside your CRM, or how it compares to native Salesforce assignment rules. If you are choosing between assigning to a person and assigning to a queue in the first place, our guide on how to assign leads in Salesforce walks through all four native methods.

Frequently asked questions

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

Set the record OwnerId to the queue Id. Queues are Group records with Type equal to Queue, so add a Get Records element on Group filtered by Type equals Queue and DeveloperName equals your queue API name, then set OwnerId to that record Id in a before-save Flow or through an Update Records element in an after-save Flow.

How do I find a queue ID in Salesforce?

Open the queue in Setup and read the Id from the URL, or query the Group object where Type equals Queue. The better practice inside a Flow is not to use the Id at all: look the queue up by DeveloperName at runtime, so the Flow keeps working when you deploy it to a sandbox or another org where the Id is different.

Can Salesforce Flow assign a Task to a queue?

Yes. Task queues are supported, provided the queue has Task added as a supported object in Setup. Assign it the same way as any other record, by setting OwnerId to the queue Id. Be aware that a task owned by a queue sits unowned until a user accepts it, so it will not show up in anyone individual task list before then.

Can Flow trigger Salesforce lead assignment rules?

Not on its own. There is no standard Flow element that re-runs assignment rules. The established pattern is an invocable Apex method that sets the assignment rule header on the record and updates it, called from a record-triggered Flow. If you would rather not maintain Apex, set the owner directly in Flow or use a routing layer beside Salesforce.

Should I use a before-save or after-save Flow for assignment?

Before-save, in most cases. Setting OwnerId on the triggering record needs no extra DML in a before-save Flow, so it is faster and avoids re-triggering other automation. Use after-save only when the same Flow also has to do something beyond the record itself, such as sending a notification or creating a related task.

Why does my Flow keep reassigning the same record?

The entry conditions match records the Flow just changed, so it fires again on its own update. Tighten the conditions, for example by requiring that OwnerId is not already the queue, or switch on the option that only runs the Flow when a record is updated to newly meet the conditions. Both break the loop.