I was asked today about MOSS's behavior when workflows are changed midstream. Say I have a document library with a Workflow attached to it, start a few long-running (non-immediate) workflows, then change the workflow before they're completed - will they keep running? Will they use the new workflow or the old, from that point on?
I had hoped for the former, but expected the latter. You can't switch flow in midstream (if you'll pardon my mishmash of similar metaphors), since a newer activity might rely on a variable created by a previous action - one that never took place.
Armed with a burning scientific curiosity and a lack of something to do while the motorway was jammed due to an accident, I set out to check my hypothesis:
1) Create a document library with three fields - two text fields and a Yes/No field. The two text fields represent actions taken before and after the change, while the yes/no field is to simulate a long-running workflow that requires other user's interaction:
2) Create a simple workflow that updates the Step1 field and then waits around until the Waiting field is set to No:
This worked fine, of course - a new document would start the workflow and get its field set to Step1, then wait until I unchecked the Waiting field and then completed. I created another document and left it in the Waiting state.
3) Update the workflow and add another action after waiting - simply setting a value to the post-wait Step2:
4) Try it out. I created a new document and verified that Step1 was set before waiting, and Step2 set after waiting. Then I unchecked the Waiting flag on the old document, created with the original workflow.
As expected, Step2 did not get assigned for that document. Despite the fact that the latest version of the workflow had a new action after the Wait, the document was attached to the older version of the workflow, and not the newer. This was also true when I added the second action in a different Workflow Step, rather than a second Action in the same step.
This can be easily seen inside Sharepoint Designer, where we can see that the Workflow's XOML file is just another file stored in just another document library - and like any other document library, it supports file versioning:
This is a potential cause for confusion - if we have many workflows active and are then required to make a change to it, it's hard to know which workflow is running for which document. The ideal solution would be to complete or terminate all workflows before making a change, but that's hardly a realistic solution for modifying production systems.