Versions and publishing
A reference for the publishing model behind the Workflow Library: what a draft is, what publishing produces, and what a device runs when you change something.
Draft and published
Every workflow is in one of two states that matter day to day.
| State | What it means |
|---|---|
| Draft | Exists only in the Workflow Library. No agent can see it. |
| Published | A version of it is available to your organization's agents. |
A published workflow can also have unpublished changes, which happens as soon as you edit one. The changes sit as a draft on top of the published version. Devices keep running the published version until you publish again.
What publishing produces
Publishing creates a version: a snapshot of the workflow at that moment, recorded permanently and never edited afterwards.
The snapshot is self-contained. It carries the content of the components the workflow uses rather than pointing at them, so a version keeps working the way it did when you published it even if the components it was built from change later.
Publishing a workflow that is already published replaces the live version. The dialog says so, and agents pick up the new one.
Version history
Open a workflow and select History. Versions are listed newest first, and each entry shows:
- The date and time it was published.
- Live on the version currently published, if the workflow is published at all.
- Its tag, if it has one.
- How many steps it has.
- How long ago it was published, and who published it.
Two controls sit on each entry: view its details, and roll back to it. Roll back is absent on the live version, since you are already on it.
Before the first publish the panel reads "No versions available yet."
Version tags
Publishing offers an optional Version tag, a short label such as stable,
pre-audit, or hotfix. It has no effect on behavior and exists so you can tell
versions apart at a glance in the history.
The tag is the one part of a version that can be changed after the fact. Everything else in a version is fixed.
Changing a published workflow
Editing a published workflow does not affect devices until you publish. You have three ways out of a draft:
| Action | Effect |
|---|---|
| Publish | Creates a new version and makes it live. |
| Discard Draft | Throws the unpublished changes away. The live version is untouched. |
| Unpublish | Returns the workflow to draft and withdraws it from agents. |
Unpublishing keeps the version history. Old versions stay browsable, and publishing again creates a new version rather than restoring the old one.
Rolling back
Rolling back to an earlier version replaces both the live version and any draft you have in progress. The confirmation says so. Unpublished work is lost, so publish or discard deliberately before rolling back rather than finding out afterwards.
Editing with others
Changes to a workflow save on their own, about a second after you stop typing, and straight away when you leave the name or description field. While a save is under way the header reads "Saving...". Once it is done it shows when the workflow was last saved. If a save fails, it reads "Changes not saved".
Several people in your organization can have the same workflow open at once. When two of you change different parts, for example one renames the workflow while the other edits a step, both changes are kept. Nothing asks you to choose.
When someone else saved a change to the same thing you are changing, your change is held back and a notice appears above the name:
Someone else saved changes to this workflow while you were editing. Keep your changes or use theirs?
| Choice | Effect |
|---|---|
| Keep my changes | Saves your version over theirs. |
| Use theirs | Drops your change and shows what they saved. |
The steps count as one thing here. If you both changed steps, even different ones, you get the notice.
Publish, Discard Draft, Unpublish and roll back act on the workflow as you last loaded or saved it. If someone else changed it since then, the action is refused and nothing changes.
- In the editor, an unsaved change of yours is saved first (Discard Draft drops it instead). If that change clashes with theirs, you get the notice above and the action does not run: make your choice, then run it again. Otherwise the message reads "Someone else saved changes to this workflow while you were editing. Review their changes and try again." and the editor shows their version. Check it, then run the action again.
- On the Workflows list, the message names the workflow, for example "Laptop setup was changed by someone else. Reload and try again." Reload the page, then run the action again.
What a run actually executes
A run is pinned to the version that was live when it started, and stays on it.
Publishing a new version, rolling back, or unpublishing does not change what a run already underway is doing. Those affect the next run, not the current one.
When publishing is refused
A workflow needs a name and at least one step before it can be published at all. Until it has both, the button is disabled.
Publishing is also refused when steps have unresolved problems, usually a required parameter that has not been filled in. The app lists the offending steps by number and name with a count of issues on each. Fix them and publish again.
Who can do what
| Viewer | User, Admin, Owner | |
|---|---|---|
| View workflows and version history | Yes | Yes |
| Create and edit workflows | No | Yes |
| Publish, unpublish, roll back, discard a draft | No | Yes |
| Edit a version tag | No | Yes |
Related
- Your first deployment for building and publishing a workflow start to finish.
- How Coldsea Deploy works for why publishing is the handoff to your devices.