Say you have version 1 of a custom workflow running and being used by your end users, and later on when you have version 2 ready to deploy. You may have many instances of version 1 in progress, and you certainly don’t want to disrupt these running workflows – they should be allowed to continue running as version 1 until they are complete. Likewise, you want any new instances of the workflow started by end users to start and run as version 2.
MOSS workflows don’t support versioning in a straightforward sense, where you can seamlessly deploy successive versions of a workflow. But this doesn’t mean we’re powerless. There are ways to simulate versioning.
If you attempt to simply install version 2 over version 1, you’ll just create a headache for yourself and your users – don’t do it. You may have the idea to version your workflow assemblies, and version your workflow InfoPath forms. It’s an interesting idea, but it just doesn’t work properly.
Instead you’re going to have to deploy the subsequent version it as if it were a completely new workflow. It gets its own GUID in the workflow.xml, and has to be associated with the lists and libraries all over again. You’ll want to set the version 1 workflow to “No New Instances.” To do this, go to the list’s settings screen and go to Workflow Settings -> Remove Workflows. Here you’ll find a radio button to set the workflow to “No New Instances.” When version 2 is deployed and associated, only version 2 will be allowed to start on an item. At the same time, any currently running version 1 workflows will continue to operate normally.
This solution has weaknesses, but we can at least address them.
A major weakness is that the name of this workflow will have to be different. It’s probably advisable to simply append a _v2 to the end of the original workflow name, so you now have MyWorkflow and MyWorkflow_v2 running on the list. Even though the end users can’t run MyWorkflow anymore, you can imagine that any name change (even a simple one) can wreak havoc with a large non-technical user base. This can present a training hurdle that may be unacceptable for larger organizations.
If you have the workflow start automatically this is less of a problem, since the users will not have to explicitly tell the system what workflow to start. They don’t have to click on a particular name to use it. However, many workflow implementations are started manually by the users, so we need to come up with something that will allow them to start new versions without having to see the new name.
A solution to this requires some foresight, and is best implemented before rolling the first version out to your user base. The main idea is to come up with some alternate procedure that the users will use to start the workflow, something other than the out-of-the-box manual start-up; a ‘middleman’ application that the users interact with directly. It will either start the workflow programmatically or direct the user to the Initiation form.
Examples of this ‘middleman’ may be a webpart that includes a form that, when submitted, programmatically starts the workflow. Or it may be a link that somehow directs the user to the initiation form. Find further explanations of these ideas here: Start a MOSS workflow programmatically and here: Start a custom workflow from the context menu dropdown.
This ‘middleman’ application will need to be the standard way for end users to start the workflow, and they should be trained to use it. This way, when a new workflow version is deployed, the technical team can also alter the ‘middleman’ app to point to the correct workflow. The end users interacting with the ‘middleman’ will not have their experience altered, and the new workflow can be deployed seamlessly (at least in the eyes of the end-users).
A second weakness is that by default, a status column is added to the default view of the list or library for each workflow. Since version 2 in this case is technically a completely new workflow, it will create a new status column. This means that your default view will contain a status column called MyWorkflow and another called MyWorkflow_v2. As you continue to add subsequent versions, you keep adding columns.
One thing you can do is simply remove the version 1 column from the view. You’d probably want to wait until all instances are complete so your users can continue to monitor them as they’re in progress. This is a very manual process, though, and if you have multiple lists running the workflow, this can be too much of an administrative burden.
Thankfully, you can write code to suppress the version 1 column from the view, checking first to see that all instances are complete. You may choose to embed this code into version 2, so that it runs each time version 2 runs. Or you may come up with a scheduled process that you can control better.
In all, workflow versioning is a feature that is missing from MOSS, but with some creativity and some custom coding we can develop solutions to work around this. I’ll try to update this posting as I figure out more on this topic.
