Skip to main content
Studio dashboards turn connector data, host evidence, and structured results into a saved operational view. You can build the layout directly or ask Copilot to create and refine it. A dashboard can contain standard widgets and sandboxed generated apps.

​
Dashboard building blocks

Standard widgets cover the common monitoring shapes: The dashboard grid supports resize, drag, multi-select, contextual actions, and responsive layouts. Use variables for repeated filters such as site, tenant, host, or time range. Use transforms to derive the value a widget actually needs from a larger response.

​
Create a dashboard

1

Define the decision

Start with the question the dashboard must answer, such as “Which sites are outside latency SLO?” Avoid collecting metrics with no operating action.
2

Connect the source

Use a connector, MCP tool, host operation, or other structured source. Confirm the credential scope and tenant before saving it.
3

Add widgets

Ask Copilot to create the initial layout or add widgets manually. Give each widget a clear title, unit, empty state, and threshold.
4

Test refresh and failure states

Verify normal data, no data, partial data, authentication failure, and a slow source. A dashboard must remain readable when one panel fails.
5

Save and share intentionally

Name the dashboard for the operational question and confirm its visibility before teammates rely on it.

​
Refresh behavior

Dashboards can poll live sources. Studio coordinates shared fetches so panels that use the same source can reuse one result instead of multiplying external calls. Use a refresh interval that matches the source and decision; faster is not always better. Pause or lengthen polling for expensive APIs and during large-screen wall use. A panel should display the last successful result and a visible error state rather than turning a source outage into an empty dashboard.

​
Investigate changes

Studio can mark anomalies and apply visual filters across a dashboard. Use Explain anomaly for a focused interpretation of an unusual point and What changed to compare the current view with earlier evidence. Treat generated explanations as hypotheses. Open the underlying data and verify timestamps, units, aggregation windows, and missing records before acting.

​
History and recovery

Dashboard edits create history. Open history to inspect earlier versions and restore a known-good layout after an accidental or unhelpful change. Restoration changes the current dashboard but does not rewrite the earlier revision record. Use history before manually rebuilding a damaged dashboard. It is also the fastest way to identify whether a source change or a layout change caused a regression.

​
Wall and TV mode

Wall mode removes editing chrome and emphasizes the live grid for a shared display. Before leaving a dashboard unattended:
  • Confirm every source uses the intended tenant and read-only access where possible.
  • Remove panels that expose personal or customer-sensitive data.
  • Set a sustainable refresh interval.
  • Test reconnect and stale-data indicators.
  • Keep an operator path for exiting wall mode and restoring a failed panel.

​
Generated dashboard apps

A dashboard app is a small React application generated and stored as an immutable revision. Use one when standard widgets cannot express the interaction you need—for example, a guided calculator, a multi-step inspection surface, or a specialized topology interaction. Each improvement creates a new revision. The dashboard continues to reference a specific revision until the update is accepted, which keeps a generated change from silently replacing the running version.

​
Capability grants

Apps run in a sandbox. An app receives no external capability simply because its code asks for one. You explicitly enable the requested capabilities in app settings. Grants are:
  • Per user — your grant does not silently authorize another teammate.
  • Exact — the current capability set is hashed and bound to the grant.
  • Revision-aware — a capability change can require renewed review.
  • Origin-limited — network access is constrained to the allowed resource origins.
Review generated app capabilities like connector permissions. A polished UI does not make a broad network or mutation grant safe.

​
Improve an app

Open the app’s improvement action, describe the behavior you want changed, and review the generated revision. Test the new revision with capabilities disabled first, then grant only what the app needs. If an update breaks the app, return to the previous working revision rather than expanding permissions to make the failure disappear.

​
Troubleshooting

Connectors and MCP

Define the sources and credential modes that dashboards call.

Files and artifacts

Reopen durable dashboards, apps, reports, and artifacts across chats.