Workflow management
Once a workflow works, the next questions are who should use it, how do changes reach them safely, and how do you roll back a bad change. Workflow management answers those with:
- Sharing so you decide exactly who can run or edit a workflow, independent of your whole organization.
- Draft-and-release versioning so edits are tested before they become the version other people run.
This page is the reference for those controls. To build a workflow's instructions, files, and mode, see Workflow Builder; to run one, see Run a workflow.
The settings page
Open a workflow and choose Edit to reach its settings page. A left-hand nav switches between tabs, and the tab you're on is reflected in the URL so links are shareable:
| Tab | What it's for |
|---|---|
| Edit | The Workflow Builder—name, instructions, context, requested files, model, and mode. This is the default tab. |
| Sharing | Who can run or edit the workflow, and whether it's promoted to everyone in its scope. |
| Versions | The version timeline: what's live, what's in draft, and every previous version. |
| Runs | The run history for this workflow. |
| Danger zone | Archive, unarchive, and delete. |
Sharing and access
The Sharing tab controls access along two independent axes: specific people you invite, and whether the workflow is promoted to everyone in its scope.
Invite people
Invite a colleague by email and pick their role:
- Can run — run the workflow. This is the default, so sharing "so someone can use it" never silently grants editing rights.
- Can edit — edit the workflow, release versions, and manage its sharing.
- Owner — full control of the workflow. Shown for the creator; not an option you assign directly.
You can change a person's role or remove them at any time from the People with access list.
Promote to everyone
By default a workflow is Invited people only—just you and the people you invite can find and run it. Using the General access control on the Sharing tab, you can promote it to Everyone in your organization (or everyone in the project, for a project-scoped workflow): anyone in that scope can then find and run it, while only named people can edit.
Only an organization admin—or, for a project-scoped workflow, a project admin—can promote a workflow to everyone. If you're not an admin, invite one as an editor and ask them to promote it.
Switching back to Invited people only removes everyone-in-scope access but keeps your named collaborators.
Organization vs. project scope
A workflow is either organization-wide or scoped to a project. Project-scoped workflows appear on that project's Workflows page and run inside the project experience; "everyone in scope" means everyone in the project rather than the whole organization. See Projects for how project scope interacts with context and membership.
Workflow versioning
Every workflow tracks a series of versions. Editing builds a draft; releasing makes a version the live version—the one everyone with run access uses. Saving in the builder never changes what other people run; that only happens when you explicitly release.
Test a draft before releasing
Because saved edits stay in draft, you can run them yourself first:
- Make and save your changes in the Edit tab.
- From the Versions tab (or the workflow's run page), choose Run draft to try the unreleased version on real inputs.
- When it looks right, choose Release changes. Runners now get your latest edits; until then they keep running the current live version.
Release changes also appears in the workflow's run header whenever a newer draft exists over the live version, so editors can publish without opening the Versions tab. Releasing confirms who it affects—only you, you and your collaborators, or everyone with access—before it goes live.
The version timeline
The Versions tab lists every version newest-first, each labeled as Released (live), Draft (the latest unreleased edits), or a previous version. Expand a version to see who created it, how many times it ran, its average and total spend, and its configuration (model, mode, requested files).
Restore a previous version
To roll back, choose Restore on any previous version. Restoring copies that version's setup into a new version—nothing is deleted, and your current version stays in history:
- If the workflow has a live version, restoring makes the copy live immediately (Restore & publish).
- If it doesn't, restoring creates a working draft you can test and release when ready (Restore to draft).
Lifecycle: archive and delete
The Danger zone tab handles taking a workflow out of service:
- Archive — take the workflow out of service and stop new runs. Organization- and project-wide access are removed, but its versions and past runs are kept. Unarchiving restores it as private, with its release pointer unchanged.
- Delete — permanently remove the workflow, its versions, and its run history. This cannot be undone.
Prefer archiving over deleting when a workflow is superseded but you may still want its history or the option to bring it back.