Version, package, and deploy workflows
26R1 reference · Documentation-based tutorial draft · Not executed in IFS
Save, deploy, and trigger are different steps
Section titled “Save, deploy, and trigger are different steps”Saving preserves a diagram version. Deploying activates executable behavior. A projection reaction, event action, or workflow command connects that behavior to its entry point.
Only one version of a workflow is active. Active versions are permanently locked for editing; clone or save as another version for a change. Keep the process key stable when intentionally replacing the same workflow.
Before deployment, run diagram validation and, where applicable, command validation. The supported BPMN subset is narrower than a general Camunda diagram.
Package the complete change
Section titled “Package the complete change”Add the workflow to an Application Configuration Package from the Workflow page. The documented process includes associated projection actions, event actions, and their linked custom events.
Review the package contents rather than assuming it contains every dependency:
| Dependency | Verify separately |
|---|---|
| Workflow version | Active version exported, or latest modified if none is active |
| Trigger configurations | Correct process key, scope, timing, and enabled state |
| Page command | Relevant page configuration and context included |
| REST configurations | Target endpoint keys and authentication completed |
| Permission sets | Required workflow and projection grants reviewed |
| Custom attributes/APIs | Available and compatible in the target |
| Pending async work | Input/version compatibility considered |
Import can activate behavior
Section titled “Import can activate behavior”An exported Active workflow can be deployed automatically during ACP import. Plan the target activation sequence before importing into production.
REST configuration names, descriptions, and types can be created during import, but authentication details must be supplied in the target. Same-name configuration behavior also needs review; do not assume all values are overwritten.
A template/non-template mismatch for the same key can prevent import. Use the supported Rename Workflow Item mechanism where appropriate and recheck linked reactions.
The tooling reference notes that an enabled projection configuration can be installed even if its workflow deployment fails. Review detailed import/deployment results and actual active state; a successful validation summary is insufficient.
Verify in the target
Section titled “Verify in the target”- Confirm the intended process key and active version.
- Confirm the actual diagram and trigger settings.
- Complete REST configuration and review grants.
- Run a happy path and deliberate failure as the intended user.
- Inspect persisted records and asynchronous execution history.
- Confirm that page commands appear in the intended context.
For installer-provided workflows, inspect System Installed Workflows when deployment is missing or failed. Correct the recorded cause before redeploying.
Rollback is more than a diagram
Section titled “Rollback is more than a diagram”Undeploying the current version can reactivate a previously deployed version. Confirm the resulting active version, trigger compatibility, grants, and queued work.
Undeployment has restrictions, including system-provided workflows and the last deployed version still referenced by active configurations. Use the supported management flow instead of deleting engine records.
A version rollback does not undo business changes or external calls already performed. Document any required data repair separately and test the rollback plan in development.