When approval rules change, should in-flight documents follow the old or new workflow?
Publishing new rules should not silently change every in-flight document. Define the effective boundary, choose a treatment for each affected state and preserve document identity, previous decisions and the reason for the change.
On this page5 sections
Changing approval configuration should not implicitly decide which rules every in-flight document follows. Specify which new submissions use the new rules, then choose whether existing documents continue, migrate explicitly or are withdrawn and resubmitted. Each path should preserve the original basis for approval and the action history. This concerns running business instances, a different scope from project requirement changes and source-code handover.
Separate the process definition, document instance and people rules
A process definition describes steps and branches. A submitted document is an instance of a particular definition. A separate assignment rule may determine who currently holds the department-manager role. We recommend recording the instance's process version, relevant decision inputs and assignment policy. Decide whether the person is fixed when the document is submitted or resolved when the instance reaches a task; do not leave that choice implicit.
Camunda's versioning guidance describes its default behavior of continuing existing instances on their original definitions while new instances use the latest definition. This demonstrates a separation between deployment and migration, not a universal promise about every approval product. When reviewing a software development proposal (Chinese), ask for a demonstration using the actual product version being delivered.
Choose an explicit path for existing documents
The business owner should identify the effective time, organizations, document types and exceptions. Starting today is insufficient: specify whether the boundary is initial submission, resubmission or entry into a particular task. The following approaches have different costs and can be combined across affected states, provided each document has an unambiguous treatment.
| Path | Condition to confirm | Evidence to preserve |
|---|---|---|
| Continue on the old version | The old rule remains acceptable and authorized people can finish | Original version, decisions and actual actors |
| Explicitly migrate | Active tasks, variables and subsequent routes map correctly | Before-and-after state, mapping and authorization |
| Withdraw and resubmit | The business permits stopping the instance and handling prior effects | Old-to-new document link and withdrawal reason |
Do not delete the original and create an unrelated replacement as a shortcut. Actions already approved, paid or communicated to an external system require their own business treatment. Changing a diagram should not be represented as reversing those actions. An apparent return to an earlier workflow state does not establish that an external effect has been undone.
Include returned documents and substitute approvers in the boundary
Suppose an application was submitted before the new policy took effect and returned for correction afterward. Decide whether replacing an attachment preserves its original workflow, and whether changing the amount or department requires approval under the new rules. There is no universal answer for those different edits. The screen should explain the applicable rule and what resubmission will change.
An approver's departure does not necessarily require migration of the entire process. An authorized delegation or reassignment rule may allow work to continue, while recording the original assignee, actual actor and basis for the transfer. If the new version adds a review step, the business must decide whether instances already beyond that position need additional review. Do not assume migration automatically recreates historical steps.
Check active tasks and required inputs before migration
Inventory in-flight instances by version, active task, parallel branch and exception state, then rehearse representative cases. Camunda's migration documentation requires task mappings and describes restrictions around active elements and existing jobs. Verify the capabilities of the selected engine rather than treating identical diagram labels as proof that migration is safe.
For each migration category, specify the source task, destination task, additional variables, task owner and subsequent route. Also decide what happens when an approval arrives during migration, using an agreed pause or conflict policy. Afterward, inspect actual task assignments and historical records. A successful administrative operation does not by itself establish that the resulting business route is correct.
Accept against real running states and define rollback limits
- Submit documents on each side of the effective boundary and inspect their actual versions and branches.
- Rehearse documents at intermediate tasks, returned for editing and waiting in parallel approvals, rather than testing only new submissions.
- Replace an approver or appoint a substitute, then verify where old tasks go and how the acting identity is recorded.
- Overlap a migration with an approval attempt and confirm that the document does not progress twice, skip a step or lose an opinion.
If the new definition has a problem, restoring the old definition changes only the future behavior covered by that restoration. It does not automatically revoke completed approvals. Keep an inventory of affected instances and decide which can return to their former route and which require compensation or manual review. Put these conditions into the requirements and acceptance criteria, then verify that the delivered version, individual documents and operation evidence correspond.