Recover Existing Workflow Instances After Workflow Deployment Change

0
I recently deployed changes to an existing workflow in my Mendix application.After deployment:New workflow instances are working correctly.Existing/in-progress workflow instances are failing.The workflow instances were already running before the deployment.The issue only affects the old workflow instances.I would like to understand the recommended approach for recovering these workflow instances.My questions are:Is it possible to recover or continue failed workflow instances after workflow definition changes?Can existing workflow instances be retried or restarted?How does Mendix handle running workflow instances when a new version of the workflow is deployed?If the workflow becomes incompatible, is there a supported migration approach?Is cancelling the old workflow and creating a new workflow instance the only recommended solution?
asked
2 answers
1

Hi Sachin,

Step-by-Step: Recovering Failed Workflow Instances in Mendix


Step 1: Understand why it happened

Mendix re-validates every running workflow instance against the newest deployed model. If your deployment changed a step that an instance was currently sitting on, that instance is flagged "Incompatible." New instances aren't affected — they simply start on the new version.

Step 2: Locate the broken instances

Open the DefaultWorkflowAdmin page (from the Workflow Commons module), or query System.Workflow for instances where State = Incompatible or Failed.

Step 3: Read the "Reason" field

Each broken instance shows a Reason explaining exactly what conflict occurred (e.g., activity removed, path changed, context object issue). This tells you which fix is appropriate.

Step 4: Pick the right fix, based on the reason

  1. Retry — if it's just a transient error, not a version conflict.
  2. Restart — if it's a version conflict; restarts the instance from the beginning of the new workflow (keeps context data, loses step progress).
  3. Jump-To — if you want to preserve progress; manually point the instance to the correct step in the new flow.
  4. Abort + create a new instance — only if none of the above work (e.g., the context entity itself changed).

Step 5: Apply the fix

Use the Change Workflow State activity (or the admin page) to execute Retry / Restart / Jump-To / Abort on the flagged instances.

Step 6: Confirm resolution

After applying the fix, check that the instance's state moves back to "In Progress" or completes normally.

Step 7: Prevent this in future deployments

Before editing a live workflow, duplicate the workflow document, make your changes in the duplicate, and point new Call Workflow activities to it. This way, old running instances keep executing the original unedited version, while only new instances pick up your changes.

answered
1

Hi Sachin,

This issue is not caused by the deployment itself. I think this happens because you deleted an existing workflow and created a new workflow, or you duplicated the workflow and deleted the old one.

This issue will not happen if you modify the existing workflow by adding or deleting a user task. So, I suggest that next time you change the existing workflow instead of deleting or duplicating the workflow.

  1. Yes, for old data, you can retrieve the failed instances from the database and, in a loop, call an activity called Call Workflow. This will restart the workflow.
  2. Existing workflows can also be restarted by retrieving them based on their state from the database.
  3. If you change the existing workflow and deploy it, everything should work smoothly. If you delete the existing workflow and create a new one, the old workflow instances can go into a Failed status.


answered