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.