Skip to main content

Self-Authored Dashboards

Self-authored dashboards let operators build dashboards inside the ServiceRadar web UI without writing a dashboard package. Each dashboard is driven by one or more SRQL source queries. Each source query can produce one or more compatible outputs, and those outputs become panels on the dashboard canvas.

Use self-authored dashboards when you want to assemble fleet, site, service, availability, trend, or troubleshooting views from data already searchable with SRQL. Use the Dashboard SDK when you need to ship a custom React dashboard package with bespoke rendering code.

Finding dashboards​

Open Dashboards from the sidebar. The dashboard library shows dashboards you own, dashboards shared with you, and dashboards available through your groups.

From the library you can:

  • search dashboards with SRQL-style filters such as in:dashboards;
  • open a dashboard by its generated seven-digit ID or optional slug;
  • mark dashboards as favorites;
  • set a personal default dashboard when more than one dashboard is available.

Dashboard slugs must start with a letter and may contain lowercase letters, numbers, and dashes. Pure seven-digit slugs are rejected because those route segments are reserved for generated dashboard IDs.

Creating a dashboard​

Start from Analytics or the dashboard library and choose to create a new dashboard. A new dashboard starts with only dashboard metadata:

  • title;
  • optional description;
  • optional slug.

Save the dashboard before adding panels. This gives the dashboard a stable route, owner, generated dashboard ID, and permission boundary before panels are created.

Query-first authoring​

Dashboard panels are created from source queries. The intended flow is:

  1. Open Dashboard Creator or Settings on a dashboard you can edit.
  2. Add a source query with a label and SRQL query.
  3. Run the query.
  4. Inspect the sample rows and detected fields.
  5. Choose a compatible output.
  6. Add the output to the canvas.
  7. Drag, resize, compact, and save the dashboard layout.

The builder uses the returned schema to guide visualization choices. For example, a table-shaped query can become a table, but it should not offer an availability gauge unless the output has fields that can map cleanly to available and total values. This keeps dashboard creation from becoming a guess-and-check loop.

Source query examples​

List recent service checks:

in:services time:last_1h sort:timestamp:desc limit:25

Count devices by type:

in:devices stats:count() as total by type sort:total:desc

Build an availability rollup:

in:devices stats:count() as total, count_if(is_available) as available by type

Create a time bucket for trend panels:

in:services time:last_7d bucket:1h stats:count() as total, count_if(status:"ok") as ok by bucket

Use the SRQL Cookbook and SRQL Reference for entity names, filters, aggregations, and bucket syntax.

Visualization types​

The dashboard builder can offer visualizations based on query output shape:

  • Table for row-oriented data.
  • Stat / count for single-value metrics.
  • Gauge / availability for ratio outputs such as available versus total.
  • Bar and line charts for grouped or bucketed numeric data.
  • Pivot tables for grouped summaries where users need to compare dimensions.

Panel forms should present field selectors and display options rather than raw JSON. If a visualization requires a field such as a numerator, denominator, label, timestamp, or metric value, the builder should offer compatible fields from the source query output.

Layout​

Dashboards use a grid canvas. Editors can drag and resize panels, compact the layout after removing panels, and save the layout with the dashboard. Operators should avoid leaving single panels stranded in half-width rows unless that is an intentional layout choice.

Sharing and access​

Dashboard access is permission-aware:

  • owners and users with edit permission can change dashboard settings;
  • dashboards can be shared with individual users or reusable user groups;
  • users only see dashboards they own or have access to;
  • administrators can manage broader dashboard and user-group access according to RBAC policy.

Use groups for reusable access boundaries. Groups are not dashboard-specific; other ServiceRadar features can use the same user groups over time.

Reports and email delivery​

Dashboards can be used for scheduled reports when outbound mail is configured by an administrator. Mail settings are system-wide and live under Settings so the same outbound mail configuration can be reused by other ServiceRadar features.

Report delivery is asynchronous. A scheduled dashboard report should not block interactive dashboard viewing or editing.

Operational notes​

  • Keep SRQL source queries focused. Prefer multiple clear source queries over one query that tries to drive unrelated panels.
  • Use labels and panel titles that describe the operational question, such as "IAH workstation availability" or "Hypervisor service failures".
  • Prefer bucketed queries for trend-over-time panels.
  • Use pivot tables when the operator needs to compare multiple dimensions without exporting data.
  • Use the Dashboard SDK only when the built-in panel types cannot express the desired visualization.