A shared operations dashboard can become too broad to act on. An operations lead may need headline workload and service-health signals. A queue supervisor may care most about status, priority, intake source, and issue-type concentration. An administrator may also monitor automation health or AI-readiness signals. When every section is fixed in one sequence, each operator scrolls past information that belongs to someone else's review. The dashboard becomes a directory of metrics, not a monitoring instrument.
Latch now lets each operator select which dashboard sections appear, set the order in which they appear, and save the layout. The dashboard stops being a fixed broadcast. It becomes a monitoring surface assembled by the person who monitors.

Section visibility and ordering are saved per operator. The layout editor works with the dashboard sections Latch already provides: summary, service health, operational insight, automation, and AI readiness. An operator can keep the sections needed for a daily check, hide the rest, and move the most important section higher. The saved order returns in later sessions. This is not a shared saved view that the team negotiates; it is a personal configuration inside the operator's own access boundary.
Role-aware availability means a section appears only when the operator has access to its underlying information. Customization cannot grant access to a hidden section. It only controls visibility and order among the sections already available to that operator. That distinction keeps personalization from becoming an access-control shortcut.

What the dashboard is not. A customized dashboard is a triage surface, not an analytical report. It answers the question "is something wrong right now?" with the fewest widgets necessary. When a pattern demands investigation - a spike in reopened cases or a cluster of SLA breaches in one region - the operator turns to a saved report that holds the measure, date range, filters, and grouping. Reports are built for analysis; dashboards are built for monitoring. Conflating the two produces a board that is too heavy for triage and too shallow for investigation. If an operator finds themselves repeatedly opening the dashboard to study a widget for more than a few seconds, the work belongs in a saved report, not on the dashboard.
Decision guidance. Start by listing the conditions that demand an immediate response: work accumulating in one status, a priority mix shifting toward critical, service health moving outside its expected range, or an automation section showing a problem. Keep the dashboard sections that expose those conditions. If a question is reviewed occasionally or needs a precise date range and grouping, it belongs in a saved report rather than the dashboard scanned during the day.
Failure modes. Without personalization, operators compensate. They build shadow trackers in chat, keep a second tab open, or stop looking at the dashboard altogether. A useful signal gets buried under sections the operator does not review. The cost is not just wasted screen space; it is slower recognition of a change that deserves attention.
Personalization carries its own risk. When every operator sees a different view, team-level alignment on shared metrics can erode. The morning standup becomes a negotiation over whose dashboard is "right." The safeguard is not to force a single view, but to pair personal dashboards with a shared saved report definition that gives the team one repeatable analytical starting point. The personal dashboard is the early-warning surface; the saved report is the repeatable workspace for analysis and review.
Honest limitations. Widgets surface the measures implemented by the dashboard. They are not a replacement for composing a report definition. If an operator needs a narrower question than the available widgets answer, that work belongs in a saved report. This is an intentional boundary: the dashboard is for monitoring operational state, while the reporting workspace is for controlled investigation.
Operator-level customization is deliberately personal. Teams that want a consistent review ritual can document which sections belong in a particular role's daily check, while each operator still controls the saved layout. The dashboard does not become another global configuration that one person's preference changes for everyone else.
The customization layer extends the reporting capabilities introduced in the operational reporting release and the metrics philosophy described in queue health measures beyond first response. The key addition is operator-level control over what the dashboard shows, without requiring administrative changes to the shared view.
A dashboard that tries to serve every analytical question serves none of them well. Keep the dashboard focused on the sections an operator checks repeatedly. Move questions about a defined time window, grouping, or reusable analysis into a saved report.
Read the full context in the July product update.