Skip to content
Monomer

View, filter, and refresh a dashboard

Open Dashboards and select a dashboard in your workspace. If it asks for inputs, complete them and choose Show results. These opening inputs, such as a reporting period or account selection, stay fixed for that entry in History.

Use the input controls provided by the dashboard to change its interactive values. Each dashboard defines its own controls, so a region selector or date filter appears only when its author included one. Open History to inspect earlier results and Show query runs to check query activity and failures.

A dashboard can keep a previous completed result visible while a replacement is running. Check the current inputs and activity before treating the displayed values as the refreshed answer.

Metric results group days, weeks, and months in the Workspace’s Reporting time zone, and the dashboard names the zone its results used, such as Times in UTC. Results keep the zone they ran with; after the zone changes, choose Run again to see the dashboard in the new one.

Refresh a widget or change the opening inputs

Section titled “Refresh a widget or change the opening inputs”

Choose Refresh this widget from a widget’s menu to request new data for its current inputs, or Retry in a failed widget. Each action refreshes only the queries that widget uses; it does not restart unrelated queries. Inspect query activity for failures or work still in progress.

To change the opening inputs, choose Change inputs, review the current values filled into the dialog, edit them, and select Show results. The new results open as a new entry in History, preserving the earlier results. To run the current definition again with the same inputs, choose Run again from More actions. It may ask you to confirm inputs if the current parameter names changed.

After a definition change is applied, use Run again or Change inputs to open results for the current definition. Existing results preserve the definition they opened with. If the new results still look wrong, ask the author to inspect the applied definition, not just the draft.

Explorer members and higher can open Dashboards and explore their results. Viewers read results through Pages, where they can use the dashboard’s own input controls; Change inputs and Run again aren’t available there. From a dashboard Page, Explorer members and higher can choose Open dashboard. If a result is denied, check your current Workspace role and access. For a different layout or calculation, ask your agent to edit the draft, then review and apply it.

The agent reads the dashboard and follows its advertised Session collection. To use an existing entry, list Sessions and read the selected path. To run the current definition with fixed opening inputs, describe the collection’s open entry with monomer_describe, then invoke it with kind: DASHBOARD_SESSION_OPEN and complete parameterBindings. Include every declared Parameter, using explicit null for nullable values; {} is valid only when no Parameters are declared.

open saves the definition and Parameters as an immutable Session and starts every named query with its initial Variable values asynchronously. Its ACCEPTED response returns a Session result.path, without result rows or a queryRuns selection map. Read that path. runningQueryRuns shows only activity still RUNNING; an empty array can mean the initial queries have already finished.

  1. Describe the Session’s advertised resolve entry, then invoke it with kind: DASHBOARD_SESSION_RESOLVE and variables copied from the Session body’s initialVariables. For later input changes, send your complete map of selected values. Include every declared Variable and explicit null where needed. {} is valid only when there are no Variables; it does not fill defaults or preserve previous values.
  2. Keep the response’s validated variables and complete queryRuns map together. Each map value is a QueryRun path. The Session does not store your selection or expose the Draft’s readyResults.
  3. Read each QueryRun path. While its state is RUNNING, read it again to observe completion. When SUCCEEDED, follow its advertised READ operation for the result child to read columns and rows. A SUCCEEDED run’s result READ can still return an unavailable error if its saved artifact cannot be read or verified. Do not treat that failure as empty rows.

resolve chooses the latest successful run matching the inputs and current query plan within the same Session. If none exists, it joins a matching RUNNING run or starts a new one. FAILED and CANCELLED runs are not reused. Reading Sessions, QueryRuns, or results does not start queries.

To request fresh data or retry selected queries, describe and invoke the Session’s refresh entry with kind: DASHBOARD_SESSION_REFRESH, complete variables, and a non-empty unique queryNames array from its definition. Refresh skips successful-result reuse for those names but still joins matching RUNNING runs. It starts no unselected queries: those keep matching SUCCEEDED or RUNNING runs, or matching FAILED or CANCELLED runs if needed. If any unselected query has no matching run, the whole refresh is rejected with REFRESH_QUERY_RUN_UNAVAILABLE; resolve the inputs first. Follow refresh’s returned queryRuns in the same way. Neither operation cancels shared runs or changes another reader’s selection.

To show the selected results in the conversation, the agent calls monomer_show with the Session path and a selection holding the same variables and queryRuns from the latest resolve or refresh. Clients that support MCP Apps display a live, read-only view; other clients receive a link. Call it again after a new resolve or refresh. See MCP tools.

To read through a Page, follow the Page Session flow.

Choose History from More actions to see when the dashboard was created, applied, or deleted, who made each change, and the app they used when recorded. Select a change to read its complete saved definition. Older records may have no recorded person or app. In the sample Workspace, the dashboards Monomer created during setup show Monomer as the person. This definition history is separate from the header’s History, which shows earlier inputs, results, and query runs.

Explorer members and higher can read definition history, including after the dashboard is deleted. A living dashboard’s earlier definitions are read-only.

Delete a dashboard or restore its definition

Section titled “Delete a dashboard or restore its definition”

Explorer members and higher can choose Delete dashboard from More actions. Check the current dashboard name, the linked Page paths, public access, schedules, and running-query impact, then type the current name exactly to confirm. If the linked Pages cannot be loaded, choose Retry linked pages before deleting.

Deletion removes the dashboard, its draft, results, schedules, and every linked dashboard Page, and cancels its running queries. Public readers lose access to those Pages too. Definition history stays available from the deleted dashboard’s activity or its saved History link. If another person deletes a dashboard you have open, its Viewer or draft shows This dashboard was deleted. with links back to Dashboards and History.

In a deleted dashboard’s definition history, choose Restore on the deletion record or Restore this version on an earlier available version. It returns with its original dashboard ID and the selected definition. Its schedules resume for future occurrences; linked Pages and past results do not return. Add it to Pages again when you are ready to share it.

Open Schedules and select an occurrence to see its fixed inputs and original query results. Reopening or reloading that result does not start new queries. Use Explore these results to explore separately without replacing the recorded scheduled result. Query success and your permission to read its result are separate; a denied widget is not a failed or empty query. See Schedule a dashboard for setup, history, and missed-run behavior.