Promote Multiple Workflows
Use bulk promotion when several Workflows or a folder of Workflows must move through the same Environment release path. The Console promotes each Workflow separately and reports its outcome, so you can identify which releases need attention.
Before you begin
The Site must support Release Management. You need permission to promote the selected Workflows and access to both the source Environment and the next higher-ranked Environment. A selection can include v1 Runtime and v2 Runtime Workflows.
Review dependencies before selecting the batch. The Console processes Workflows one at a time; it does not release the selection as one transaction or determine a safe business dependency order for you. If a caller depends on a new Sub-Workflow contract, release compatible changes in the required order. Configure the target Environment's Connections separately.
Select the Workflows
- Open
Workflowsfrom the main navigation. - Select the Workflows or folders you want to promote. Folder selection includes the Workflows inside those folders.
- Click
Promotein the selection actions to openPromote Workflows. - Review the selected Workflow names and the Environment cards.
An empty folder provides no Workflows to promote. If no promotion route is available, check that you have access to two adjacent Environments in the Site's configured order.
Review readiness
The dialog checks the selected Workflows against the Environment revisions and shows counts for the available release path. Its initial states describe what was read when the dialog opened:
| State | Meaning |
|---|---|
To promote |
The source and target revisions differ. |
Looks up to date |
The revisions matched when checked. They may change before the promotion request reaches that Workflow. |
No revision here |
The source Environment has no revision to promote. |
Not checked |
The initial revision check did not establish the state. |
For a large selection, the dialog can skip the initial per-Environment checks and display a notice. Promotion still reports an outcome for each Workflow it processes.
Enable v2 Runtime Workflows after promotion
Select Enable each Workflow in the target Environment if the v2 Runtime Workflows should be enabled as part of this batch. The option is off by default and requires permission to manage Workflow status. Check the target Connections, Cluster, and intended activation behavior before selecting it. v1 Runtime Workflows in a mixed selection are promoted without this enable operation.
The Console attempts enabling after a Workflow is promoted or found up to date. When the source has no revision, the Console still submits the enable request and labels the result Not enabled, nothing published there. Check the target Environment's actual revision and status before relying on that label. It does not attempt enabling after a conflict or a failed promotion or publish.
Enabling has a separate result from promotion. If promotion succeeds but enabling fails, the target revision remains promoted. Resolve the status error without assuming you must repeat a successful release.
Promote and inspect outcomes
- Select
Promotefor the source and its adjacent target Environment. - Review the Environment names in the confirmation and confirm the promotion.
- Wait for the progress count and per-Workflow outcomes to update.
- Open any Workflow that needs attention and inspect its revision, publish state, and reported error.
| Outcome | What to do |
|---|---|
Promoted |
Verify the target release and the Workflow's intended activation state. |
Up to date |
The promotion found no change to apply. |
No revision |
Save or release the required source revision before trying again. |
Changed while promoting |
Review the concurrent change and retry from the intended current revision. |
Publish failed |
A target revision exists but is not published as expected. Resolve the reported problem and publish that revision again. |
Failed |
Inspect the message and current target state before retrying. Do not assume that no change reached the target. |
If the same failure repeats, the dialog can stop making additional checks to distinguish a write failure from a publish failure. It displays a notice when later failures are reported with less detail.
When the enable option is selected, also review its per-Workflow outcome:
| Enable outcome | Meaning |
|---|---|
Enabled |
The status was set to Enabled in the target Environment. |
Could not be enabled |
Review the separate status error; this does not change the promotion result. |
Not enabled, nothing published there |
The batch found no source revision and reported no effect from enabling. Check the target's published revision and status; this label does not replace that check. |
Stop or retry a batch
Click Stop to stop the batch. Closing the dialog also stops the Console from starting subsequent promotion requests. A request already in progress can still finish, and Workflows already promoted remain promoted. Any completed enable operations also remain in effect.
After resolving a failure, select the affected Workflows and repeat the appropriate promotion. Confirm the final revision and published state for every required Workflow, then test the released interface. For v2 Runtime Workflows, also review their Environment-specific enabled status; a published revision and an enabled Workflow are separate states.