Versions

A dataset version is the rows exactly as they were at one moment: after one pipeline run, one upload, one edit. Versions are numbered v1, v2, v3 and never change once written. The active version is the one the rest of the product reads.

1. Writerun, upload, edit, delete
2. New versionv(n+1) written, v(n) kept
3. Activatebecomes the active version
4. Downstreamalerts, outputs, dashboards

What creates a version

Action	Where	Source shown in the rail
A pipeline run publishes	Scheduled, manual, Refresh or triggered run of the producing pipeline	Pipeline run
A rerun merges rows	Rerun {n} rows on a dataset that feeds another pipeline	Rerun
Upload a file	Upload to {worksheet}… on the dataset page, replace or append	Uploaded
Import a file as a new dataset	Upload data on the Pipelines page	Uploaded
Rows arrive over the ingest API or an input integration	Automatic, or Sync on the dataset page	Ingested
Generate sample rows	Generate data in {worksheet}…	Sample data
Jason imports data into a new dataset	Chat	Imported by Jason
Jason transforms the dataset	Chat	Transformed by Jason
Jason publishes rows from work in a conversation	Chat	Published by Jason
A dataset is copied from another workspace	Copying pipelines between workspaces	Copied
Edit a cell	Edit in the row dialog, or the row page’s Data tab	Copies the previous version’s source
Delete rows	Select rows, Delete {n} rows	Copies the previous version’s source
Add, rename or delete a worksheet	Header menu, Worksheet section	Copies the previous version’s source

Two things follow from this. First, a version is a complete snapshot of every worksheet, not a diff, so opening v3 shows you all the rows as they were, even if v4 only changed one cell. Second, a dataset with no versions has no data at all; the page shows “No data yet” until the first run, upload or ingest.

A run that fails verification does not publish. The last good version stays active, so a broken source never replaces good rows with empty ones. See Verification and repair.

The versions rail

The rail on the left of the dataset page lists every version, newest first. The one you are viewing is highlighted.

• Current. The active version, the one everything else reads, under its own heading.
• Day groups. Every other version under the day it was written: Today, Yesterday, then dates.
• Each row. “v7 — Sep 23, 14:02”, then the row count and the source label from the table above (“8,426 products · Pipeline run”). An icon on the left shows the source: the producing pipeline’s own icon for a pipeline run, a file icon for an upload, and so on. The coloured left edge groups sources: green for pipeline runs and ingests, blue for uploads, violet for sample data, purple for Jason, grey for copies.
• Filter versions… Narrows the list to versions whose number, date, row count or source contains what you type, for example uploaded or Sep 14. “No versions match.” when nothing does.
• Load older versions. The rail loads the 20 most recent versions. This link at the bottom loads the next 20.
• Collapse. The rail’s collapse button shrinks it to a column of icons. Hover an icon for its version, date and source. The choice is remembered in your browser.

The breadcrumb also ends with the version number, and the row count under the title is the count for the version you are viewing.

Viewing an older version

1. Click a version in the rail. The grid reloads on that version’s first worksheet, with page, sort and filter reset.
2. Browse as usual. Worksheet tabs, sorting, filtering, Run query and the row dialog all work against the version you chose. Exports from the header menu export that version.
3. Step through versions. With the page focused (not a text box), the Up arrow opens the next newer version and the Down arrow the next older one.
4. Return. Click the version under Current, or press the browser’s Back button.

The address bar carries ?version=2 while you are on a chosen version, so you can send a colleague a link to exactly what you are looking at. Each version you open is a new history entry, so Back and Forward step through the versions you viewed.

There is no restore button. The UI lets you view older versions; making an older version active again is not something you can do from the page. If you need the old rows back, export the older version and upload it, or ask Jason.

Roll the Live product offers dataset back to yesterday’s version and tell me what changed between the two.

What reads the active version

Everything that consumes a dataset resolves the active version at the moment it reads, unless a link pins a version.

• The dataset page opens on the active version.
• Dashboards run each card against the active version when the dashboard is opened. To see a dashboard as it was, pin its datasets to earlier versions with Latest data → Data as of. See Dashboards.
• Alert rules are evaluated when a new version is written, comparing it with the version before. See Alert rules.
• Outputs (Google Sheets, webhooks, Snowflake, BigQuery, Postgres, MySQL and S3) receive rows when an alert rule sends them. An Every update rule sends the whole dataset after each new version; other rules send only the rows that match. See Alert rules and Warehouses and storage.
• Share links show the active version only. Viewers cannot open older ones. See Sharing.
• The serve API, MCP and the CLI return the active version.
• Pipelines that use the dataset as an input read the active version when their run starts.

Editing rows is copy-on-write

Editing a cell, or deleting selected rows, never touches the version you are looking at. The whole worksheet is copied, your change is applied to the copy, the copy is written as the next version, and that version is made active. The previous version keeps the old value, and the row’s history is visible by opening the older version.

This has two practical consequences:

• Edits survive until the next publish. If the dataset is produced by a pipeline, the next run publishes a fresh version from the source. A hand edit to a collected value will be overwritten if the source still says the old thing. For a lasting change, ask Jason to change the pipeline instead.
• Edits are cheap to undo. Open the previous version to see what the value was. To put it back, edit the cell again.

Because an edit is a new version, it also triggers everything a publish triggers: alert rules are evaluated against the change, rules that send rows to outputs run, and dashboards show the new value the next time they load. A column_changed rule on the column you edited will fire.

Versions and the pipeline

Dataset versions and pipeline versions are different things. A pipeline version is a revision of the pipeline itself: the steps, sources and checks. A dataset version is one set of rows. One pipeline version usually produces many dataset versions, one per run; a repaired pipeline version resumes the failed run and publishes the next dataset version from where it left off.

The row page’s View menu links from a row to the pipeline run that produced its version, and the run’s Outputs tab links back to the dataset version it published. See Run detail.

Reading a version history

A typical history for a pipeline-produced dataset, newest first, and what each entry tells you:

Row in the rail	What happened
Current: v8 · Transformed by Jason	Jason added a discount_pct column in chat. This is what dashboards, alerts and outputs are reading until the next run.
Today: v7 · Pipeline run	This morning’s scheduled run published.
Yesterday: v6 · Pipeline run	Yesterday’s run failed, Jason repaired the pipeline, and the resumed run published. The run itself (open a row’s full page and choose View → Pipeline run) shows it was a resumed run. See Verification and repair.
Sep 20: v5 · Rerun	Twelve rows were sent back through the pipeline with Rerun 12 rows and merged in.
Sep 20: v4 · Pipeline run	Someone edited a cell; the edit copied v3’s source forward. Open v3 to see the value before the edit.
Sep 20: v3 · Pipeline run	A normal scheduled publish.
Sep 16: v2 · Uploaded	A file was appended from the dataset page while the pipeline was being set up.
Sep 16: v1 · Pipeline run	The first run, at the end of the build.

Two versions with the same source a few minutes apart usually mean an edit or a row deletion; a version with no run behind it (an upload, an edit) has no Pipeline run link on its rows.

Troubleshooting

• The run completed but there is no new version. A run publishes only when it finishes successfully with rows that pass the checks; a test run or a debug run never publishes, and a completed run that is still being finalised shows “Awaiting publication” on the pipeline page. Open the run’s Outputs tab to see what it produced. See Run detail.
• The version count is climbing faster than the schedule. Edits, row deletions, uploads and Jason’s changes each add one. Type uploaded or Jason in Filter versions… to find them.
• An output shows old rows. Outputs receive rows only when an alert rule sends them. Check that a rule points at the output, then open the output’s page for its last delivery status. See Integrations overview.
• I opened a link and the data looks stale. The link carries ?version=. Click the version under Current in the rail.

Retention

Older versions are kept according to the workspace’s data retention setting. When a version expires, alert history that referenced it keeps its record but no longer links to the rows. See Data retention.

What’s next