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, destinations, dashboards

What creates a version

Action	Where	Version source shown in the chip
A pipeline run publishes	Scheduled, manual or webhook run of the producing pipeline	pipeline_run
Upload a file	Upload to {worksheet}… on the dataset page, replace or append	upload
Import a file as a new dataset	Upload data on the Pipelines page	uploaded
Rows arrive over the ingest API or a source integration	Automatic	ingest
Edit a cell	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
Generate example rows	Generate data in {worksheet}…	synthetic
Jason transforms the dataset	Chat	Copies the previous version’s source
A rerun merges rows	Rerun {n} rows on a dataset that feeds another pipeline	rerun_merged

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 version chip

The chip in the dataset header shows the version you are viewing.

• Grey v4. You are viewing the active version.
• Amber Viewing v2. You are viewing an older version. A Back to current link returns you to the active one.
• The list. Every version, newest first, with its source (pipeline_run, upload, ingest and so on, as in the table above) and how long ago it was written.

The breadcrumb trail 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. Open the version chip and choose a version. 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 detail all work against the version you chose. Exports from the header menu export that version.
3. Return. Choose Back to current or reopen the chip and pick the version tagged current.

The address bar carries ?version=2 while you are on an older version, so you can send a colleague a link to exactly what you are looking at.

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 widget against the active version when the dashboard is opened, and recompute when a new version lands. See Dashboards.
• Newsletters read the active version when an issue is generated.
• Alert rules are evaluated when a new version is written, comparing it with the version before. See Alert rules.
• Destinations (Google Sheets and outgoing webhooks today; warehouses and cloud storage coming soon) receive the new active version after each write. See Sheets, warehouses and webhooks.
• 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 on the row page, 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, destinations receive the version, and dashboards recompute. 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:

Entry in the chip	What happened
v7 · pipeline_run · current · 2 hours ago	This morning’s scheduled run published. This is what dashboards, alerts and destinations are reading.
v6 · pipeline_run · yesterday	Yesterday’s run failed, Jason repaired the pipeline, and the resumed run published. The run itself (open a row and choose View → Pipeline run) shows it was a resumed run. See Verification and repair.
v5 · pipeline_run · 2 days ago	A normal scheduled publish.
v4 · pipeline_run · 3 days ago	Someone edited a cell on the row page; the edit copied v3’s source forward. Open v3 to see the value before the edit.
v3 · pipeline_run · 3 days ago	A normal scheduled publish.
v2 · upload · last week	A file was appended from the dataset page while the pipeline was being set up.
v1 · pipeline_run · last week	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 and uploads each add one. Check the chip for upload entries and edits between runs.
• A destination shows old rows. Destinations deliver after each version; open the integration’s page for its last delivery status. See Integrations overview.
• I opened a link and the data looks stale. The link carries ?version=. Press Back to current.

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