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. Sharing collaborators and promoting a workflow to everyone in a project or organization is available on Business and Enterprise. Individual plan workflows stay in your account. 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, whether it's promoted to everyone in its scope, and which organization or project it is filed in. |
| 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. New workflows start as Invited people only—saving in the builder never changes who can find or run them.
Invite people
- 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.
If the workflow has no live version yet, inviting someone also releases the current draft so they have something to run. Later edits still stay in draft until you release them.
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.
Promoting to everyone also releases the current draft if there is not yet a live version. 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.
Scope is set on the Sharing tab, not in the builder form. Creating from a project's Workflows page files the new workflow in that project; creating from the top-level Workflows page files it organization-wide. You can move it later with the Scope control. After a move, only you and invited people can access it in the new location; named collaborators keep their access.
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, choose Run draft to try the unreleased version on real inputs. The run page shows a Draft badge so you can tell it apart from the live version.
- When it looks right, choose Release on the draft row (the confirmation dialog says Release changes). Runners now get your latest edits; until then they keep running the current live version.
Use Release on the draft even for the first live version, before anyone else has a version to run. Release changes also appears in the workflow's run header whenever a newer draft exists, 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:
- The live version is labeled Released and offers Run.
- The latest unreleased edits are labeled Draft and offer Run draft plus Release.
- Previous versions collapse by default and offer Restore.
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). From this tab you can also jump back to Edit draft (or Edit, before the first release).
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 Invited people only, 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.