Publishing & Versions

A business process goes through a draft-publish cycle. Editing a diagram changes only the draft; publishing deploys a new version to the engine. Running instances are not affected by a new version — they finish on the version they started on.

To move running instances to a new version, migrate them — see Migrating running instances.

Draft and published state

A process can be in one of two states:

  • Draft — the diagram has been edited but not yet published. The draft is visible only in the editor and does not affect the engine.

  • Published — the diagram has been deployed to the engine as a new version.

When you open the editor on a process that has both a draft and a published version, you see the draft. To discard the draft and revert to the last published version, use the rollback action.

Publishing a new version

To publish, open the diagram and use the Publish action. A dialog prompts for an optional comment that becomes part of the version record.

Publishing deploys the current draft to the engine as a new process definition version. The draft is cleared, and the process now has a new published version.

If the diagram contains errors that prevent deployment — for example, an invalid expression — publishing fails and the draft is preserved.

Version history

Every time a process is published, a new version appears in the version history. The history shows the version number and the deployment timestamp.

You can download the diagram file for any version in the history — useful for comparing changes or reverting to an older design.

Rollback

The rollback action discards the current draft and reverts the editor to the last published version. This does not affect any running instances or the version history — it only clears the unpublished draft.

Migrating running instances

Migration moves running instances from one process definition version to another.

When to migrate

After publishing a new version, instances started under the previous version are still running the old diagram. If the new version fixes a problem or changes the workflow in a way that should apply to those instances, you can migrate them to the new version.

How migration works

  1. Open the Executions tab (on a specific process) or the Instances list (in the top-level navigation).

  2. Select one or more instances. All selected instances must be on the same process definition version.

  3. Choose Migrate and select the target version.

  4. Map source activities to target activities. The migration plan shows which activity in the old version corresponds to which activity in the new version. You can also remap variables if needed.

  5. Confirm the migration.

The migration runs as a background job. After it finishes, a report shows how many instances migrated successfully and how many failed.