Saved queries

Every query worth running twice belongs in the Saved Queries library: a workspace-wide, searchable catalog of SQL with its source binding, model binding, tags, and dashboard dependency tracking.

What’s in a saved query

Each saved query maintains:

• Identity & metadata: Query name, description, tags, and a favorite star.
• SQL buffer & binding: The SQL statement, its bound data source, and optional data model binding.
• Visual steps: Queries created in the visual query builder store their step DAG (builder_steps) alongside compiled SQL for full round-trip editing.
• Where it is used: every dashboard card, report, story, presentation, presentation or story template, metric (and alert on it) and Warehouse dataset that reads it (see where a saved query can be used).

Authoring entries

From the top-right of the Saved Queries page, New query opens a page with both ways to write one:

• SQL query: Opens a clean Monaco workspace in the SQL editor.
• Visual query: Opens the canvas in the visual query builder to build a query from visual steps.

Blank SQL query, beside New query, opens the SQL editor in one click.

Save a query from the editor

Choose Save, name the query, and it joins the library below. Saving applies the same safety check as running it on the query’s source: a statement that would be refused when run (anything but a single read-only SELECT or WITH query that DataSquares can parse in that source’s SQL) is not saved, and the error says why.

1. Write or edit the SQL you want to keep, then choose Save in the toolbar.

   

2. Give the query a name and, if you like, a description. Both make it easy to find later.

   

3. The tab now carries the query name and no unsaved dot. Find it again under Saved, or on the SQL library page.

   

Browsing and filtering

The library is a rich, responsive table with URL-synchronized state for bookmarking and sharing:

• Full-text search: Search across query names, descriptions, and raw SQL text.
• Tag filtering: Multi-select tags from your workspace tag registry.
• Source & model filters: Filter queries bound to specific data sources or semantic data models.
• Dashboard & Unused filters: Filter by a specific dashboard or click Unused to isolate queries not referenced by any dashboard card (ideal for catalog cleanup).
• Favorites toggle: Click Favorites to filter for starred queries.
• Sorting & pagination: Sort by Recently updated, Name (A–Z), or Newest. Page sizes support 25, 50, or 100 rows per page.

Per-query actions

Each row and detail drawer provides:

• Run: Opens the SQL editor and executes the query immediately (/sql/new?q=<id>&run=1).
• Open in SQL editor: Opens the query in a dedicated editor tab without running.
• Open in visual builder: Available for queries with visual steps, reopening the node canvas.
• Add to dashboard: Drops the query directly onto a dashboard as a live SQL card.
• Import to DataSquares: Materializes the query result into the managed warehouse (when the Warehouse feature is licensed).
• Duplicate: Clones the query while preserving SQL, description, source binding, and model binding.
• Copy SQL: Copies the query’s SQL text to the clipboard.
• Favorite: Toggles query favorite status.
• Delete: Confirms deletion. While anything reads the query, the delete is refused and the message names each thing that reads it; see what deleting a saved query does.

Deleting a saved query of your own that nothing uses

Deleting a saved query normally needs the SQL editor’s delete permission, which the built-in Editor role does not have. One delete never needs it: a saved query you created that nothing uses. Nothing uses it when no dashboard card (a deleted dashboard’s included), metric, dataset, story, report, presentation (a slide or its speaker notes, a deleted presentation’s included), presentation or story template, or saved version of a dashboard, report, story or presentation names it, and it has no grant, no tag and no one else’s favourite (your own favourite doesn’t count). Such a delete removes the query alone and never cascades to anything. Like every saved query’s delete, it is permanent: a deleted saved query does not go to the Recovery Center.

The AI chat’s Save to dashboard relies on it: when it saved a query for the card and the card then could not be added, it takes the query back, whatever your role. Through the API it is DELETE /api/saved-queries/{id} from a signed-in session; an API key needs the delete permission as before. In the library, Delete shows to roles that can delete queries.

Find and run saved queries

Search, favourite and run queries from the library.

1. Open SQL to see every saved query. Filter by data source, model, dashboard or tag, or show favourites and unused queries only.

   

2. Search by name, description or SQL text, and choose how to sort the list.

   

3. Select the star to make a query a favourite. Favourites are easy to filter to later.

   

4. Select a query to open it beside the list. There you can read its SQL, run it, add it to a dashboard, open it in the editor, copy it or duplicate it. Edit, Delete and the tag editor show only to roles that are allowed them: the Author role here sees no Delete and cannot change tags.

   

5. Run, in the query panel or in a list row, opens the query in the SQL editor and runs it straight away.

   

Bulk management & CSV export

• Bulk actions: Multi-select queries on the current page to apply workspace tags or perform batch deletion. Queries that something reads are kept during bulk deletion; delete them one at a time to see what reads each.
• CSV export: Click Export on the header to download a CSV summary of the current filtered list (including names, descriptions, sources, tags, usage, timestamps, and SQL).

The detail drawer

Clicking any query row opens the side drawer:

• SQL preview & copy: View formatted SQL and copy it with one click.
• Tag editor: Add or remove workspace tags.
• Name & description editor: Update query labels and documentation.
• Used in N places: Lists everything that reads this query (dashboards, reports, stories, presentations, presentation and story templates, metrics, alerts on those metrics and Warehouse datasets), each a link to it where it has a page, so you know what a change reaches. A story, presentation or template you can’t open is counted, never named (“1 presentation you can’t open”). The Used in column of the library shows the same count.

Editing SQL by hand is one-way for visual queries

If a query was created in the visual query builder, editing its SQL by hand — in the SQL editor or detail drawer — and saving discards its visual steps permanently. The query becomes SQL-only and cannot be reopened on the visual canvas.

To preserve the visual steps: make edits within the visual query builder, or duplicate the query first before editing raw SQL.

Queries on dashboards

Add to dashboard (or the canvas’s SQL insert card) binds the saved query to a dashboard card:

• The card re-queries the source directly on refresh or parameter change.
• Central management ensures that updating a saved query propagates to all linked dashboard cards.
• On SQL Server, Azure SQL and Azure Synapse sources, a dashboard filter or a parameter’s list of values reads the saved query as a table named __dsq. A saved query that starts with WITH keeps its common table expressions at the start of the statement that reads it. The saved query is refused, with the reason, when one of its common table expressions is named __dsq, when it has a WITH inside parentheses (a table hint such as WITH (NOLOCK) is fine), or when its WITH is not a list of common table expressions (such as WITH RECURSIVE, which T-SQL does not have).

Where a saved query can be used

A saved query is a data source in every product below. Wherever it is read, it meets the same checks: its SQL must pass the safety check for its source; a person whom row-level security restricts on its source is refused, because a saved query can’t be filtered to their rows (on a public or password link, that is the person who made the link: see What a link visitor gets); and a column with a sensitivity label is refused to anyone whose role may not read it, and to everyone on a shared link or in a Warehouse dataset.

Where	How it reads the query
Dashboards	A live SQL card. The page and cross filters reach the columns the card shows, on shared links and embeds as when signed in.
Reports	A query block.
Stories	A live number or a data block.
Presentations	A KPI tile, chart or table bound to it (Add to presentation).
Metrics	A metric that reads one aggregate over a column of the query. Editing the query’s SQL or source makes the next version of each such metric, clears its certification and tells its owner.
Warehouse	Import to DataSquares copies its rows into a managed dataset. A dataset carries neither row-level security nor sensitivity labels, so a query on a source with row-level security, or one that reads a labelled column, is not imported; see what refuses an import.

Lineage draws each of these from the query. Lineage and search by meaning name saved queries only to people who may read them (the View permission on the SQL menu, as this library asks); lineage counts them for everyone else.

What deleting a saved query does

A delete is permanent. So that nothing breaks silently, it is refused while anything reads the query:

• Only dashboard cards read it: you are asked whether to delete the query and those cards together.
• Anything else reads it (a report, story, presentation, presentation or story template, metric, alert or Warehouse dataset): the delete is refused, even with the cards, and the message names each, and nothing is deleted. Remove the query from each first. Stories, presentations and templates you can’t open are counted, never named.

A metric is never deleted with its query.

Related

• SQL editor — Monaco-based SQL workspace with draft recovery and AI.
• Visual query builder — step-by-step query construction without SQL.
• Canvas basics — using SQL cards on dashboard canvases.
• Warehouse — importing saved queries into managed datasets.