Short answer: a list view chart is a single grouping of the records already in the list, drawn as a donut or a bar chart, and it exists to tell the person working that list where their attention should go. It cannot group twice, cannot reach another object, cannot be scheduled and cannot be put on a dashboard. The moment a request needs any of those, you are describing a report and should build one instead of fighting the chart.
What a list view chart is
Open a list view in Lightning, click the chart icon at the top right, and a panel opens beside the list. Charts belong to the object rather than to a single view, so a chart you create is available from any list view on that object, and it always redraws against the records in whichever view is currently open.
That second point is the whole design. The chart inherits the view’s scope and filters, so switching from “My Open Cases” to “All Escalated Cases” redraws the same chart against different records. It is a lens on the list, not an independent object.
Creating one
You supply three things:
- Chart type. Vertical bar, horizontal bar or donut. Horizontal bars are the right choice when the grouping values are long text, which they usually are.
- Aggregate. A count of records, or a sum of a numeric or currency field.
- Grouping field. One field. Picklists work best. A text field gives you one slice per distinct string and looks like static.
That is the full configuration. No filters of its own, no second grouping, no formatting options. It is deliberately minimal and it is fine.
What they are genuinely good for
The honest use case is a queue. A support agent working a case list sees the priority split without leaving the list. A salesperson on an open pipeline view sees where the value is concentrated by stage. In both cases the chart answers a question and the answer is one click from the records themselves, which is the part a dashboard cannot match.
They are also free in a way reports are not. No folder, no sharing decision, no place in the report tree for somebody to maintain. For a small team with a working list, a chart beside it costs nothing to keep.
Where they stop
Be clear with stakeholders about the ceiling, because the requests always escalate in the same direction:
- One grouping only. Cases by priority, yes. Cases by priority and by owner, no.
- No cross-object fields beyond what already exists on the object, so cross-object formula fields are the only way to chart a parent’s attribute.
- No drill-down. Clicking a segment does not filter the list underneath it.
- No history or trend. The chart shows now, always.
- No subscription, no scheduled email, no dashboard placement, no export of the chart data.
- No conditional formatting, colour control or target lines.
The filtering limits of the underlying list view apply too. A list view filter grid does not traverse relationships and does not do the row-level logic a report can, so a chart of a list is always constrained by what the list could select in the first place.
When to build the report instead
Switch as soon as any of these are true. Somebody outside the team needs the number. The question has two dimensions. Anyone says the word “trend”. The figure must arrive in an inbox on a Monday. The criteria cannot be expressed in the list view filter grid.
The stronger pattern in most orgs is both. Keep the list view with its chart for the person doing the work, and build a report or dashboard for the person watching the work. They answer different questions and they do not compete. What causes trouble is trying to make one do the other’s job: a dashboard that managers use to pick their next task, or a list view chart that a director quotes in a board pack.
Frequently asked
Can I share a list view chart with specific users? Charts follow the object, not a sharing model of their own. Anyone who can see the object and open a list view can see the charts defined on it, and the data they show is still filtered by their own record access.
Why does my chart show different numbers to a colleague’s? Because the underlying view returns different records. Scope set to “My records” and ordinary sharing both cause it, and neither is a fault in the chart.
Do list view charts deploy between orgs? They are metadata associated with the object and move with it in a source deployment. Recreating one by hand takes about twenty seconds, which is often the quicker route.
