Update old version

Update old version lets you apply the same configuration change to one or more older, already-published versions of a workflow in a single operation — without rebuilding each version by hand. This is useful for bulk remediation and keeping multiple running versions consistent, for example pushing a corrected value or a node fix into versions that are still processing in-flight requests.

Because in-flight requests stay pinned to the version they started on (see App versions), a fix you make in the current draft does not reach requests already running on older versions. Update old version is how you back-port that fix to those versions.

What you can update

When you start, you first pick the type of configuration to update. Four types are supported:

• Nodes — update Action, Function, Approval, Input, or Async Callback nodes.
• Forms — modify form field configuration across versions.
• Permissions — update visibility conditions for Approval and Input nodes (node/field permissions).
• Global constant — modify global constant values across workflow versions.

Apply an update

1. From the Custom workflows list, open the workflow's row actions (⋯) and click Update old version.
2. Select the update type. Choose one of Nodes, Forms, Permissions, or Global constant, then click Continue. (A banner reminds you that changes apply only to the versions you select in the later steps.)
3. Select the item. Pick the specific node, form, or constant you want to change. Only items that exist in the workflow's versions are listed.
4. Select versions. The dialog shows the versions where that item exists. Tick the versions you want to update, then click Continue.
5. Make the change. You're taken to a focused editor for the chosen item, pre-filled with the baseline config (taken from the latest version you selected). Edit the value/configuration and click Save. A "Version updated successfully" confirmation appears.

What happens when you save

For each version you selected, the system:

1. Takes an archived snapshot of that version's current state first, preserving its original version metadata — so the prior state is retained for history and recovery.
2. Increments the version's sub-version (for example, 3.0 → 3.1) and applies your change to that version in place.

The change is applied to all selected versions in one operation. Requests already running continue on their existing logic; the updated configuration takes effect per the platform's version-pinning rules.