Versions, Staging and Production

You edit the draft. Save version freezes it as a numbered version. Deploy puts a version into Staging or Production, and each environment runs only what was deployed to it.

The draft and its versions

The draft is what the builder edits. Save writes it; nothing else does.
Save version freezes the draft, with its parameters, as the next numbered version. It moves no environment, so it is a restore point.
Restore copies a version back into the draft so you can edit from it. The builder asks first, because whatever the draft held that is in no version is lost.
Compare is a tab in the builder. It shows what changes between any two of the draft, Staging, Production and a version, value by value: the canvas with each added, changed or removed node marked, every changed setting with its old and new value, SQL and expressions line by line, links and parameters. A value that looks like a credential is reported as changed but never shown. Every place that compares opens it already filled in.
Timeline is a tab with everything that happened to the pipeline, oldest first: versions saved and deleted, deploys and rollbacks, reviews, a restore, a change to the pipeline's own settings, and a reset of what a source has already read. A version saved after another one shows what changed since that one. The timeline exports as a CSV, or as a report to print or save as a PDF.
Versions is a tab with the list of versions and what you can do with each. While the draft holds work that no version has, it says so at the top, with Compare and Save version.

Deploying

Deploy puts a version into an environment, from one dialog: From the draft or any saved version, To Staging or Production.

Staging takes any version. Deploying the draft saves it as a version on the way.
Production takes the version Staging runs now, or one Production has run before. The draft never goes straight to Production, so nothing reaches Production for the first time without having been in Staging.
Rolling back is deploying an earlier version to Production, with a note saying why.
If someone else deployed to the same environment while your dialog was open, your deploy is refused rather than silently replacing theirs.

Every deploy is recorded: who, when, which version replaced which, and the note.

Reviews

A workspace's owner, or an administrator, can make deploys of the workspace's pipelines wait for someone else. Every rule is off until it is switched on, and pipelines outside workspaces are never affected.

Deploys to Staging need review. A new version goes to Staging only after someone else approves it.
Deploys to Production need approval. A new version goes to Production only after someone else approves it.
Staging must have run it. A version reaches Production only after a run of it has succeeded in Staging.

Under a review rule, the Deploy dialog becomes Request review: you say what the change does and why, add a change ticket if your change process has one, and pick whom to ask. The people offered are everyone who could make that deploy themselves; for Production that means Production access on every connection the version uses. Asking needs only what deploying to Staging needs, so the people who build a pipeline do not need Production access themselves.

A reviewer you picked opens the builder's Review tab: who asked and why, what changes value by value, the connections, schedules and Flows it will touch, and how the version has run in Staging. They approve it, or reject it with a reason. A first deploy, where the environment runs nothing yet, has no changes to list, so the tab says so and opens the version on the canvas instead.
Approving deploys nothing. Once approved, you or the reviewer deploys it, when you choose. The approval lasts until the environment changes or a newer request replaces it; Staging moving on to another version does not undo an approval for Production.
Nobody approves their own request, and no role is exempt from the rule.
Rolling back to a version an environment ran before skips review, but needs a written reason, which the approvers are sent.
Requests, approvals, rejections and deploys are on the Timeline, with who and when.
The people a request asks, and the person who asked when it is approved, rejected or closed, are told in the notification bell at the top of every page, and by email when a mail server is set up.

The rules govern deploys. A Production schedule's timing and values, a connection's Production settings, uploaded files, server settings and Flows change what an environment does without a deploy; those changes are recorded in the audit trail instead.

How the environments differ

Connections. Every connection has a Staging side and an optional Production side. A run in Production uses the Production side, so the same pipeline reads the staging database in Staging and the production database in Production.
Production needs permission. Deploying to Production, running there, or scheduling there needs Production access on every connection the version uses. Nobody has it implicitly, administrators included.
Each environment keeps its own list of files it has read. Testing in Staging never makes Production skip a file.
Files uploaded to a pipeline are one copy, read by both environments.

Running

The Run dialog asks which environment to run once the pipeline has a Production version, and preselects neither.
A pipeline runs once at a time in each environment, for each set of text parameter values: while a run with the same values is waiting or going there, Run is refused and names that run. A Test run is never held back.
A schedule belongs to one environment and runs whatever version that environment holds when it fires. A deploy never changes a schedule.
A run executes the version it was queued with, so a deploy while a run is waiting changes nothing for that run.
A run whose connection has nothing on the side it needs fails, naming the connection, so a schedule never skips silently.

Reading the chips

A pipeline shows each environment's version as a chip: Staging v3 and Production v2. Draft means saved work that is in no version yet; Draft · v8 means the draft is exactly version 8. Clicking an environment's chip shows that version read-only, with its last run on the canvas.