Question for you:

Say you have a process with 3 activities, and you create 10 instances of that process.

Then you modify that process to add another 3 activities and deploy it. So your process now has 6 activities.

Then you create another five instances after the deployment, so you have 15 process instances in total.

How many instances should be completed after all 6 activities?

 

The answer is: 5.

The original 10 process instances will still complete after 3 activities. Only the new instances, put in play after you changed the process, will run through all 6 activities.

The notion that process instances are tied to workflow versions is both a blessing and a curse. The blessing part happens when a new version of the process contains a flaw. The instances created under a previous version won’t be affected. The curse reads pretty much the same: When a new version contains a cool change, the instances created under previous versions won’t be affected.

I can give you a specific example: I developed a nice feature for one of my projects. The feature requires the inclusion of a new process-level data field. When put through its paces in a development environment, it seemed to work flawlessly — but that was only because we were generating new instances to test it against. Had we tested it against older instances, we would have seen these older instances blow up because the new process data field does not exist in the older workflow versions.

This may be a post you’ll read time and again, because it’s difficult to develop along these lines.