> ## Documentation Index > Fetch the complete documentation index at: https://docs.serval.com/llms.txt > Use this file to discover all available pages before exploring further. # Building dashboards > Building analytics dashboards with Catalyst Catalyst can build analytics dashboards for your team directly from natural language. When you describe what you want to see, Catalyst will: * Design the widgets * Run them against your data * Stage the dashboard as a draft you can review *** ## What Catalyst can build An analytics dashboard is a collection of widgets arranged on a grid, backed by workflows that query your data. This can include Serval data (like tickets, access requests, assets, and workflow runs), as well as any data from connected apps (like ServiceNow or GitHub data) or public APIs. Catalyst can author dashboards with any combination of: * **Charts**: bar, line, area, and pie charts * **Tables**: row-level views, top-N lists, detail grids * **Stats**: single-number KPIs (counts, averages, sums) with trend indicators and sparklines * **Text**: section headers and inline commentary * **iFrame**: embeds of external content (only certain sites that explicitly support embedding) * **JSON**: raw structured output, useful for debugging Each widget is wired to a workflow Catalyst writes for you. Widgets can share workflows when they read the same dataset (for example, a stat and a table both summarizing the same query), which keeps the dashboard lean. *** ## Tips for better dashboards Catalyst handles dashboards best when you give it three things up front: * **Purpose**: What question the dashboard answers ("ticket triage health", "access request volume by team", "device fleet status"). * **Time range:** The default window for the data ("last 30 days", "this quarter", "year to date"). * **The widgets you have in mind**: A rough sketch is enough ("a count, a trend chart, and a breakdown by priority"). If your request is ambiguous, Catalyst will ask a couple of targeted clarifying questions before building. ### Example prompts * "Build me a dashboard for ticket triage over the last 30 days. Total open tickets, a trend chart, top assignees, and a breakdown by priority." * "Access requests by app (Figma, GitHub, AWS, Salesforce, Ramp) with approval times and denial rates." * "CrowdStrike detections and Qualys vulnerabilities by severity, trended weekly." * "Offboarding SLA dashboard: time from Workday termination to Okta deactivation and license reclaim." *** ## Time-range variables Most dashboards include a time-range variable so the whole dashboard can be scoped to a window from a single control. Catalyst wires this up automatically when you mention a time range in your request, and uses the range you specified as the default. After publishing, you can change the range from the dashboard controls without re-running Catalyst. If you'd rather lock a widget to a specific data slice (for example, a "Q1 results" widget that shouldn't move with the dashboard's time control), say so explicitly, and Catalyst will use concrete values for that widget instead of wiring it to the variable. *** ## The build process When Catalyst builds a dashboard, you'll see activity in three phases: * **Register the dashboard.** Catalyst commits the dashboard's name, time-range variables, and an empty layout. The dashboard appears as a draft in the side panel immediately. * **Build each widget.** For every widget on the plan, Catalyst writes a workflow, runs it against your data, optionally previews the widget inline in chat so you can confirm it looks right, then attaches it to the dashboard. * **Finalize the layout.** Once every widget is built, Catalyst arranges them on the grid and updates the dashboard with the final layout. Throughout the build, you can view and explore the draft dashboard. After Catalyst builds the initial version of the dashboard, you can continue to chat with Catalyst to iterate on dashboards before publishing. ### Sharing workflows across widgets Catalyst is deliberate about workflow reuse. If two widgets read the same dataset (for example, a count and a table both summarizing tickets by priority over the same window), they'll share a single workflow. This makes the dashboard easier to maintain and faster to refresh. When widgets read genuinely different data (different time windows, different fields), Catalyst writes separate workflows. *** ## Editing a dashboard Catalyst can edit dashboards you've already published. Common edits include: * **Add a widget**: "Add a stat showing total resolved tickets to my triage dashboard." * **Edit a widget in place**: "Change the trend chart to weekly buckets instead of daily." * **Remove a widget**: "Drop the assignees table from the triage dashboard." * **Rename or re-describe the dashboard.** * **Change the time-range variable**: "Default to last 90 days instead of last 30." Simply @mention the dashboard and Catalyst will find it. Edits are staged in the resource panel in the same way a brand new dashboard does, and **Publish** applies the changes to the live dashboard. ### Removing widgets Removing a widget is an explicit action. If you want a widget removed, you must explicitly ask Catalyst to remove it. ### Iterating on a widget If a widget doesn't look right (wrong chart type, wrong columns, wrong grouping), tell Catalyst what to change. It will update and re-render the preview so you can confirm the new format before publishing. *** ## Reviewing and publishing When Catalyst finishes, you'll have a dashboard draft in the resource panel. From there you can: * Open the dashboard preview to confirm the widgets render correctly and the layout reads well. * Open any individual widget to inspect its workflow and configuration. * Click **Publish** to save the dashboard. Widget workflows are scoped for dashboard rendering only and are not exposed to the help desk agent. *** ## Related What Catalyst can do Get familiar with the Catalyst interface Enable Catalyst, open your first session, and publish a change Using Catalyst to analyze ServiceNow tickets and build automations Stage changes, propose reviews, and configure approvers Natural language prompting, manual edits, versioning