Queue
A queue is a Salesforce ownership and routing mechanism that holds records and makes them available to a defined group of users until one of them takes ownership.
Definition
A queue is a Salesforce ownership and routing mechanism that holds records and makes them available to a defined group of users until one of them takes ownership. It is the platform's answer to the question: "Who works this record next?" when the answer is "whoever from the team grabs it first." Queues are commonly used for Leads, Cases, Tasks, and custom objects where the work needs to flow to a pool of people rather than a single named owner.
Each queue has its own list of members (users, public groups, roles, role-and-subordinates), and the queue itself acts as the record owner until a user manually accepts ownership or an assignment rule routes the record out. Queue members see the records in the queue's list view and can take ownership with one click. Reports can filter by queue ownership, so it stays visible who is sitting on backlog. Queues support multi-object assignment, so the same queue can hold Leads, Cases, and custom records together, although most teams keep one queue per object for clarity.
How queues route work across teams in Salesforce
Queue ownership versus user ownership
When a record is assigned to a queue, the OwnerId field stores the queue ID instead of a user ID. The record is still owned, just by a group construct. Field updates, sharing rules, and reports treat queue-owned records the same as user-owned records for permission checks. The platform displays the queue name in the Owner field, and the Change Owner button shows queue members in the user picker alongside individual users. The behavioral difference is that queue-owned records appear in the queue list view for everyone with access.
Members and access models
Queue membership can include individual users, public groups, roles, and roles with subordinates. The role and role-with-subordinates options let queues automatically inherit users from organizational hierarchy, which is useful for large support teams where headcount changes frequently. Public groups are the most flexible because they can mix users and roles. The queue settings page also supports a checkbox to send an email notification when a record is added to the queue, which is the most common way teams know there is new work.
Supported objects and assignment rules
Queues work natively for Lead, Case, Task, Knowledge Article, Service Contract, and any custom object marked Allow Queues in Object Manager. Assignment Rules for Leads and Cases can route records into queues automatically based on field values, like Industry equals Technology routes to the Tech Sales queue. Custom objects can be routed by Flow, Apex triggers, or Process Builder. The "Send Notification Email" checkbox on the assignment rule entry controls whether queue members are emailed when a record arrives.
Taking ownership and round-robin distribution
Queue members typically take ownership by clicking Accept on a queue list view. This re-assigns the OwnerId from the queue to the user. Round-robin distribution requires custom Apex or Flow because Salesforce does not ship a native round-robin algorithm for queues. Many AppExchange packages exist for sophisticated routing (Lean Data, Distribution Engine, ShellBlack), and lightweight teams build their own with a counter field plus a Flow that increments and assigns. Without round-robin, the first-come-first-served pattern produces uneven workload.
Reporting on queue records
Queue ownership is fully reportable: filter Owner.Type equals Queue, or filter Owner.Name equals the queue label. Reports like "Open Cases in Tier 1 Support queue" or "Leads in Marketing Triage queue, older than 24 hours" are foundational service-management dashboards. Pair the queue-ownership filter with a created-date filter to surface aging records that no one is taking. Most teams build a stale-queue dashboard within the first month of queue rollout.
Queue access through profile and OWD
Queue access depends on two settings: the object's organization-wide default sharing setting, and the user's profile or permission set permissions. A user must have at least read access to the object to see queue records. Public Read or Public Read/Write OWD lets every user with object access see queue records. Private OWD requires explicit sharing through queue membership, sharing rules, or role hierarchy. Plan OWD before deploying queues because the access model has cascading effects.
Queues for tasks, knowledge, and other object types
Task queues hold un-assigned activities that a team needs to work through, useful for follow-up call lists or document review pools. Knowledge queues route articles to subject matter experts for review and approval. Service Contract queues route renewal pipeline. Each object's queue behaves the same way: the queue owns the record, members can take ownership, and reports filter on ownership type. The pattern scales beyond Leads and Cases when the work needs pool-based ownership.
How to create and configure a Queue
Creating a queue takes about ten minutes. Making it actually work for the team takes longer because the routing rules, notification settings, list views, and reports all need to line up. Plan the membership model and the email-notification preferences up front because changing them after the queue has records produces noisy false alarms.
- Identify the team and the objects
Decide which team needs pool ownership and which objects flow through them. Tier 1 Support handling Cases is the textbook example. Marketing Triage handling Leads is another. A custom Service Request object handling internal IT tickets is the typical custom-object pattern.
- Create the queue
Setup > Queues > New. Enter a name and email address (the queue mailbox that receives notifications when records arrive). Choose the supported objects: Lead, Case, Task, custom objects with Allow Queues enabled.
- Add members
Pick users, public groups, roles, or roles-with-subordinates as members. Public groups give the most flexibility because they can mix user types. Avoid hard-coding individual users for queues with high turnover; use a role-based model instead.
- Enable email notification on the queue
Check the "Queue Email" field and provide an address. The platform sends an alert to this address whenever a new record arrives. For team mailboxes, use a distribution list rather than a personal inbox so coverage stays uninterrupted during vacation.
- Build the assignment rule (Lead and Case)
Setup > Lead Assignment Rules (or Case Assignment Rules) > New. Add rule entries with criteria that match the team's intake pattern, and route matching records into the queue. Activate the rule for the relevant intake channels (web-to-case, email-to-case, manual creation).
- Create the queue list view
Build a list view filtered to OwnerId equals the queue, sorted by priority and age. This becomes the team's daily work surface. Add columns for the fields they need to triage: created date, priority, source, customer name.
- Build the aging-queue dashboard
Create a report showing queue-owned records older than a service-level target (4 hours, 24 hours, 3 days). Surface it on a dashboard with thresholds. This is the operational visibility that keeps queues from becoming a black hole.
Internal name and user-facing label. Both appear in the Owner field UI and the list view picker.
Which objects the queue can hold. Lead, Case, Task, Knowledge, Service Contract, and custom objects with Allow Queues enabled.
Who can see and take ownership of records in the queue. Required for the queue to be useful at all.
- Salesforce does not ship a native round-robin algorithm for queues. First-come-first-served distribution produces uneven workload. Build a counter-based Flow or install an AppExchange package for fair routing.
- Queue email notifications can flood inboxes during high-volume periods. Use a team mailbox or distribution list instead of personal email addresses, and consider digesting to a daily summary.
- Custom objects need Allow Queues enabled in Object Manager before they appear in the queue-supported-objects picker. The setting is per-object and easy to miss during initial setup.
- Records assigned to a queue still need profile or sharing access for users to see them. Queues do not bypass OWD or profile restrictions; they layer ownership on top of the existing access model.
- Round-robin and ownership-rotation tools change OwnerId frequently, which can fire ownership-change triggers and sharing recalculations. Test trigger behavior in sandbox with realistic data volumes before going live.
Trust & references
Cross-checked against the following references.
- Queues OverviewSalesforce Help
- Create QueuesSalesforce Help
- Lead Assignment RulesSalesforce Help
Straight from the source - Salesforce's reference material on Queue.
- Create QueuesSalesforce Help
- Case Assignment RulesSalesforce Help
- Public GroupsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Queue?
Q2. What can queues hold?
Q3. What's a modern pattern?
Discussion
Loading discussion…