Versions, drafts, and publishing

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). Publishing is also the only thing that adds an entry to version history — see Version history below. 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] Everything that reads a query without going through its editor — a query’s own schedule, any monitor watching it, and any public link or embed built from it — reads the published version, never a pending draft edit. See Scheduled refresh for the schedule case.

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

A version is a published snapshot, not a save. Editing and saving a draft — even many times, even a full rewrite of the SQL — adds nothing to version history by itself; only publishing (or restoring an old version, which publishes it again) records a new entry. If you make several draft edits and then publish once, history gains exactly one new version covering all of them together, not one per edit.

Each entry shows its 1-indexed version number, a snapshot of the query as it was published, who published it, and when. There’s no limit on how far back this history goes, but there’s also no way to see an in-between draft state that was never published — only what actually went live.

[!NOTE] This is deliberate, not a gap: version history exists to answer “what has everyone been looking at, and when did that change,” which only publishing (or restoring) actually does. If you want a checkpoint of work in progress before it’s ready for an audience, publish it — you can always keep editing the draft afterward.

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.

Unpublish

Unpublish takes a live query or dashboard back to draft — the inverse of Publish, for when something should stop being visible without deleting it. It’s available from the same menu as Publish, once the object has been published at least once.

For a query, unpublishing only sets it back to draft: version history and every past published snapshot are untouched, so a later Publish (or a Restore of an old version) makes it live again with nothing lost. While unpublished:

• The workspace stops seeing it as published; anyone without edit access sees nothing until it’s republished.
• Any public link or embed built from it stops serving data — it keeps its token and starts working again automatically the moment the query is published again, no need to recreate the link.
• Its schedule stops running.
• Any monitor reading it stops checking entirely and keeps whatever state it was last in — it does not fall back to evaluating the draft, and it does not flip to “unknown.” Checking (and normal notification behavior) resumes once the query is published again.

A dashboard works the same way for its own visibility, public links, and schedule, with one difference: a dashboard has no version history or restore, so unpublishing it clears its published snapshot outright rather than setting a flag. A later Publish rebuilds the snapshot from the current draft — nothing about a dashboard’s unpublish/republish cycle depends on history that doesn’t exist for dashboards in the first place.

Fork

Fork creates a brand-new query, owned by you, copying the source query’s connector, 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.
• Alerts overview — why a monitor evaluates the published version, and what happens to one when its query is unpublished.
• Public links — why a link keeps working across an unpublish/republish cycle instead of needing to be recreated.