Dashboards

The dashboards admin area governs the dashboard experience across the organization — which widgets are available, what’s enabled, and the defaults people start from. It’s the configuration behind the Dashboards section.

Curating the widget palette centrally is a small decision with a large payoff for consistency. When every team builds dashboards from the same supported set, a coverage number or a compliance-readiness tile means the same thing wherever it appears — which matters when a program review pulls dashboards from several projects side by side. Left uncurated, dashboards drift into personal, incomparable views; governed here, they stay a common language for program health.

Available widgets and defaults

You control which widgets are available and can enable them broadly, set sensible defaults so a new dashboard starts useful rather than blank, and reset to defaults when a configuration has drifted. Curating the widget set this way means people build their dashboards from a relevant, supported palette rather than a sprawling list.

Project context

Dashboard configuration takes project context into account, so the widgets and defaults can reflect what’s appropriate for the work in a given project. A project that doesn’t use a module shouldn’t be offering that module’s widgets, and configuring this centrally keeps the dashboard experience coherent.

Configure here, use there

This area sets up the building blocks; people then assemble and read their own dashboards as described in Configuring dashboards & widgets and Coverage, quality & compliance. Good defaults here mean less setup for everyone and a more consistent view of the program across teams.