Core
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 making a workflow available in projects or your 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, its default project, and the projects or organization it's available 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 has three sections:
- People — specific people you invite to run or edit the workflow.
- Default project — the project the workflow runs in by default. It doesn't share the workflow with anyone.
- Available in — where everyone can find and run it: your whole organization, specific projects, or both.
New workflows start with no one but you—saving in the builder never changes who can find or run them. The Share button on a workflow's run page opens the same People and Available in sections; change the default project on the Sharing tab.
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 list. The current owner can transfer ownership to an existing collaborator from that person's role menu. The new owner receives full control, and the previous owner becomes a Can edit collaborator.
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.
Default project
The Default project is the project a workflow opens in by default, and where scheduled runs go, or No project. It doesn't share the workflow with anyone: until you make it available somewhere, members of the default project can't find it.
Creating from a project's Workflows page makes that project the default; creating from the top-level Workflows page leaves it with no project. Copies go to the project you copy from, not the original's default project. To change it later, pick another project (or No project) in the Default project picker and confirm. Changing it doesn't change who can find, run, or edit the workflow.
Available in
Available in controls where everyone can find and run the workflow. Only the people in People can edit it.
- Everyone at your organization — lists the workflow in every project and on the top-level Workflows page. Use it for approved processes the whole firm should run.
- Projects — makes the workflow available to the members of specific projects. The default project is marked Default project and has its own switch, so you can keep a workflow in a project while you test it there and turn it on for the project's members when it's ready. Use Add to a project to make it available in other projects too, and the × on a project row to remove it.
The workflow's owner, and organization admins who have access to it, see every project the workflow is available in, even projects they aren't a member of, and can remove it from any of them. Organization admins also count as admins of every project, so they can add the workflow to any project or make any project its default. Other editors see the projects they're in by name, plus a count of the rest—for example, +2 other projects. The run page shows projects the same way.
A project admin can also take a workflow off the project's list: on the project's Workflows page, choose Remove from project from the workflow's menu. Its members can no longer find or run it there.
While the workflow is available to everyone at your organization, the project rows are shown dimmed because they don't add anything—everyone can already find and run it. They stay in place, so turning organization access off falls back to the projects you chose.
Making a workflow available in a project or your organization also releases the current draft if there is not yet a live version. Turning availability off keeps your named collaborators.
Where workflows appear
- A project's Workflows page lists workflows with that default project or added to it, plus workflows available to everyone at your organization. The Project tab shows only the workflows with that default project or added to it.
- The top-level Workflows page lists workflows with no default project and workflows available to everyone at your organization. A workflow with a default project and only available there appears on that project's page instead.
Deleting a project leaves its workflows with no default project and removes the project from every workflow's Available in.
See Projects for how projects interact 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. It's removed from your organization and every project it was available in, and listed only in its default project's archived workflows (or the top-level Workflows archived list when it has none). Versions and past runs are kept. Unarchiving restores it for the people in 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.