# Salesforce queues: the weekly report that finds the leads nobody owns

https://salesbond.app/blog/salesforce-queues-unowned-records-audit/
Published: 2026-10-15 · Updated: 2026-10-26

A Salesforce queue is a holding place for records that do not yet have a person as their owner. A sales manager should look inside it once a week with a report of records whose owner is a queue, sorted by Created Date, because anything that has sat there longer than a few days is a lead nobody is working. The queue itself is fine. What goes wrong is that a queue never feels late, and a person always does.

## The lead that belongs to a queue

Friday one-on-one. The manager asks Tom about a lead from a trade show, a plant manager who filled in the form on Monday. Tom has not seen it. He checks: Lead Owner is “Web Leads”, the queue the whole inbound team is a member of. Priya, who sits next to him, assumed Tom had taken it because he took the two before it. Nobody took this one. Six people could see the lead for four days, and because all of them could see it, none of them felt it was theirs.

That is the whole problem with queues, and it is not a Salesforce problem. A queue is a shared inbox. Shared inboxes work when somebody empties them and fail quietly when nobody does. The failure is quiet because the record looks normal: it has a status, it has an owner field with a name in it, it appears in “All Open Leads”. Only the owner is not a person.

So the manager needs two numbers every week: how many leads are still waiting for a person, and how long the oldest one has waited. Then a third, which most teams never look at: who actually takes leads out of the queue. The rest of this article is that habit, plus enough about queues to read the report correctly.

## What a queue is, in one paragraph

A queue in Salesforce is a named owner that is not a user. The admin creates it in Setup under Queues and gives it a label, a queue email, the objects it may own (the Supported Objects box; in Trailhead’s service example that is Case, for a sales team it is usually Lead) and a list of members ( [Trailhead: Create Case Queues and Assignment Rules](https://trailhead.salesforce.com/content/learn/projects/set-up-case-escalation-entitlements/create-case-queues-assignment-rule)). Records land in a queue either because an assignment rule sends them there or because somebody sets the owner by hand. The same Trailhead project shows the mechanism end to end: the rule entry says “Case Record Type equals Product Support”, its target is the Product Support Tier 1 queue, and from that moment the queue, not a person, is the case’s owner. Queues in Salesforce work the same way for leads, and Salesforce’s own lead primer describes the two common designs plainly: some companies assign leads to a person automatically, for example by geography, and “other companies initially assign all new leads to a queue” ( [Trailhead: Track Prospects with Salesforce Leads](https://trailhead.salesforce.com/content/learn/modules/prospect-tracking-with-salesforce-leads-quick-look/track-prospects-with-salesforce-leads)). The second design is the one this article is about. It is not wrong. It just needs a report.

If you are unsure [which Salesforce license each of your five users needs](https://salesbond.app/blog/salesforce-license-types-five-person-sales-team/), start with the license count.

## Queue versus public group

A queue is about ownership; a public group is about sharing. When the Trailhead project above sets the target of a rule entry, it picks it from a “User/Queue” dropdown, so the owner of a record is a user or a queue. A public group, in Trailhead’s words, is “an admin-defined grouping of users that can be used to simplify the creation of sharing rules”, a collection of users, other groups, roles or territories “that all have a function in common” ( [Trailhead: Define Sharing Rules](https://trailhead.salesforce.com/content/learn/modules/data_security/data_security_sharing_rules)). You use a public group to say who may see records. You use a queue to say who has not taken them yet.

The two get confused because both are named lists of people that show up while an admin is building something. For the manager the practical reading is short. When the question is “where are the unowned leads”, the public groups are not where you look. Every queue is.

## The weekly unowned-records report

The base report is the first of three in [our audit of Salesforce lead assignment rules](https://salesbond.app/blog/salesforce-lead-assignment-rules-audit/): open leads whose owner is a queue, with Created Date, oldest first. We won’t repeat the setup here. Read the oldest row before the count, because a queue with twenty records from this morning is a busy team and a queue with three records from last month is a broken habit. If you suspect one channel is filling the queue faster than the team empties it, add Lead Source as a column and the pattern is usually visible at a glance.

What that report cannot tell you is the more useful half: who takes records out of the queue, and how fast?

A lead record only shows its current owner. To see the handover you need owner changes logged, and that is what field history tracking is for. Trailhead walks through it on accounts: you can “track changes on up to 20 standard or custom fields” on an object, viewed “on a record’s History related list or through History reports”, and for each field “tracking logs the date and time of change, the user making the change, and old and new values” ( [Trailhead: Enable Account Field History Tracking](https://trailhead.salesforce.com/content/learn/projects/customize-a-salesforce-object/account-field-history-tracking)). That example is an account, but tracking is set per object, and on leads the field worth tracking is Lead Owner. Ask your admin whether it is on. Once it is a history report on that field gives you, for each lead, the old owner (the queue), the new owner (a person) and the date of the move.

Group it by the new owner. Two things fall out. One is pickup speed, the gap between Created Date and the day a person’s name replaced the queue’s. The other is who is doing the picking. If the queue has six members and the report shows one or two names, the queue has six members on paper and one in practice. That second finding is worth more than the first, because no threshold or reminder fixes a team that has quietly decided the queue is somebody else’s job.

We would not turn this into a dashboard in the first month. Open both reports on Monday, read the oldest row, read the list of names, and bring both to the team meeting. The dashboard can come once the numbers are boring.

## A queue that doesn’t turn into a warehouse

![Strip of a lead's time in a queue: hours are a buffer, days are somebody's job to clear, weeks are a warehouse](https://salesbond.app/wp-content/uploads/2026/10/salesforce-queues-unowned-records-audit-2.png)

Two rules come first, and we covered them in [the catch-all queue section of the assignment audit](https://salesbond.app/blog/salesforce-lead-assignment-rules-audit/#the-catch-all-queue-needs-a-person): one named person empties the queue, and no lead stays queue-owned past a threshold you pick for your business.

The rule that article does not cover is about the queues themselves. Admins create queues readily because the setup is quick: label, email, supported object, members, save. Every new queue is one more place a lead can stop, and one more line on the Monday report that somebody has to read. So before a second or third queue exists, the person who will empty it should be named in the same conversation that creates it. If nobody can be named, the queue should not exist, and the leads should go to a person directly, even if that person is the manager.

The same test works backwards. Open the list of queues in Setup once a quarter and write a name next to each one. A queue without a name is a queue whose members all assume it is thier colleague’s, and its records belong in a queue that does have one, or with a person. Fewer queues means a shorter report, and a shorter report actually gets read.

All of this comes down to one idea: a queue is a buffer measured in hours, not a shelf measured in weeks. The report is how you find out which one you have. Who can see what sits in a queue is a separate question, covered in [Salesforce sharing rules for opportunities](https://salesbond.app/blog/salesforce-sharing-rules-opportunities-small-sales-team/).

## How this connects to assignment rules

Assignment rules and queues answer two different questions, and it helps to keep them apart. The rule answers “who should get this lead”, by matching criteria and handing the lead to a user or a queue. The queue answers “what is still waiting”. A team can have perfect rules and a full queue, because the rule’s job ended the moment it chose the queue as the target. If your rules route everything to people and the queue is only the fallback for leads that match no entry, the report in this article will usually be short, and the interesting work is in the other two reports of the assignment audit, the ones that check whether the rules fired at all. If your design is the other one, all new leads into a queue first, then the report here is the main control and the rules are a detail. Either way the report reads the same field, Lead Owner, and asks the same thing of it: is that a person? For leads from a [Web-to-Lead](https://salesbond.app/blog/salesforce-web-to-lead-lead-queue-manager-check/) form, whether they go to a person or a queue is the first thing to check.

## What happens after the name goes in

The day a lead leaves the queue, the owner problem does not go away; it moves. A lead with Tom’s name on it and no next step is only a small improvement on a lead with the queue’s name on it, which is why [the next-step rule for Salesforce tasks](https://salesbond.app/blog/salesforce-tasks-next-step-rule/) is the natural second habit after this one. Once the lead converts, the question changes from “is it owned” to “is it being worked”. On the opportunity we keep it to [the owner plus a few named roles on larger deals](https://salesbond.app/blog/salesforce-opportunity-teams-vs-account-teams/). We build SalesBond, a sales management layer on top of the CRM a team already uses. Its Deal Health checks every deal against more than 20 rules, and ownership and activity are among the categories, so a deal that stalls after a clean handover surfaces with a reason. The queue report covers the step before that. Empty the queue first, then [check your CRM with SalesBond](https://salesbond.app/).