I have been tasked with helping the deployment of a Phase 2 of a previous SharePoint deployment.
The original deployment has custom workflows that have been updated in phase 2.
Is there a "How-To" for this type of situation?
Some of the pitfalls we have seen requires you to mark the original workflow to not accept any new instances, then deploy its update as a new worflow. This would allow the previous items to finish processing under the old code and any new processes to spin up the new workflow.
One problem with this is we would then have to visit each site where the original workflow was attached and attach the new workflowV2. Now we have two workflow status columns in the doc library.
I am just getting into the project and these are problems the devs have noticed.
Any resources or hints you can throw at me would be appreciated as I am learning all of this as I go.
Here are some notes up from another dev who is giving me some background as to what he has seen:
If a version of a workflow already exists, then redeploying it as a feature will cause the existing workflow to have its status set to “No New Instances”. This can be seen by going to a document library where the workflow has been attached, select Settings -> Document Library Settings -> Workflow settings -> Remove a workflow and noting the radio button setting for the workflow. Any current, in work, workflows instances will still complete as normal, but this setting will prevent any new instances of the workflow.
Once the 2nd ‘version’ of the same workflow has been deployed, you’ll need to revisit each document library where you want it to be associated and re-add it as if it were a new workflow. You’ll have to give it a unique name, like ‘MyWorkflow_v2’. The other side-effect is that now you’ll have 2 workflow status columns in the document library. You can remove/hide the first one once all instances of it have completed and the status is no longer needed.
If you redeploy the workflow using the same feature and manifest XML files, then the internal GUID will be the same one as was used in the first deploy. SharePoint will recognize this as a second ‘version’ of the same workflow and automatically set the first version to the “No New Instances” status. If however, you choose to use a different GUID in the XML files, then SharePoint will see this as a deployment of a brand new workflow and do nothing with the existing instances. You will need to manually set each instance in each document library to the “No New Instances” setting.
After re-deploying the second ‘version’ of the workflow, you will still need to manually visit each document library where you want it used and add it to the document library. Keep in mind that its workflow template name will appear in the list of workflow templates as it is named in the XML files (which is OK), but once you add it you’ll be required to enter a unique workflow name for the workflow. This is the point you must choose something like ‘Workflow_v2” as a new name.
The retract action removes all instances of the features within the solution, specifically for my workflow application, it removes all instances of the workflow from all document libraries that it was associated with. However, in the case of , where a task is created by the workflow, once the solution is retracted if a user clicks on a task item expecting to get the signature page, they’ll instead get a SharePoint “Unknown error” page. The reason is because the retract process removed the workflow from the database and there is no longer a workflow associated with the task.