Versions, drafts, and publishing

Every save creates a new version, and a query is always in one of two states relative to what’s published: draft (edited but not yet pushed live) or published (what everyone else sees). This page covers the actions that move a query between those states.

Draft vs. published

Editing and saving a query only changes its draft. Dashboards, other viewers, and a query’s own schedule keep serving the published version until you explicitly publish your changes — so you can safely iterate on a query without breaking what’s currently live.

Who sees which one when they open the query:

• Someone with edit access to the query sees the draft (their own in-progress edit, or the published content if nothing’s been edited since).
• Everyone else — including a viewer who only has been granted the object without edit capability — is served the published columns.
• A query that’s never been published has nothing else to show, so anyone with read access sees the draft.

[!NOTE] A query’s own schedule always runs the published version, never a pending draft edit — see Scheduled refresh.

The badge next to the query name shows which state you’re looking at, along with who can see it:

Publish

Publishing pushes the current draft live — either the first time a new query goes live, or to push a further edit out to an already-published query. After publishing, the draft and published columns match until you edit the draft again.

Version history

Every save is recorded, so a query has a full version history: each entry shows its 1-indexed version number, a snapshot of what changed, who made the change, and when. There’s no limit on how far back this history goes.

Revert vs. restore

These sound similar but do different things:

• Revert loads a historical snapshot back into the current draft — it doesn’t touch what’s published. Use this to go back to how a query used to look while you keep working, without affecting anyone currently viewing the live version.
• Restore promotes a past version straight to being the published version (and resets the draft to match it). Use this when you want the audience to see that older version again, right now.

Either action can target a version by its historical version number or by the underlying change record directly.

Discard

Discard resets the draft back to match whatever’s currently published, throwing away any unpublished edits. Use it to abandon in-progress changes rather than publishing them.

Fork

Fork creates a brand-new query, owned by you, copying the source query’s data source, SQL, and options (its name becomes “Copy of <original name>”). The fork always starts as its own independent draft — editing it never affects the original query, and vice versa. Forking only needs read access to the source query, so you can branch off a query you can view but can’t edit, to explore changes of your own.

Where to go next

• The SQL editor — where Run vs. Save fits into this draft/publish model.
• Scheduled refresh — why a schedule needs a published query.