Skipping stages with ‘Change / Restart Workflow’ in Project Server 2013 and Project Online & SharePoint Designer
By blurg64
SharePoint Designer 2013 is another tool that provides a means for building workflows, what is new in the 2013 release is it can now build Demand Management workflows for Project Server 2013 and Project Online. Now I am not going to go into the specifics of the tool, as you probably already know my preference, but irrespective of that, I thought it important to share how to build workflows that leverage the Skip to Stage functionality with SPD.
Now I have been advocating using Skip to Stage in workflows forever, if your building a long running workflow, which demand management workflows always tend to be, you would be foolish not to think that the workflow will be perfect from day one and not need updating and restarting at some point. Obviously the more complex your process (and thus the number of tasks, approvals etc. that need to be reapproved / declined) the more painful it becomes to restart a workflow and then progress through to the point you were at before the restart. This is where skip to stage comes in, when the workflow is restarted using Project Server’s inbuilt ‘Change or Restart Workflow’ function and a stage to skip to is selected, the workflow is passed some special settings letting it know that it needs to restart and skip through to the stage the user chose. However, Skip to Stage only works if you build your workflow to take it into account, it doesn’t ‘just work’.
I should note, this post comes as the result of a question in the Project forums on MSDN / Technet. Specifically, the original poster was having trouble understanding what was happening when using the Skip to Stage functionality of a SPD Project Server 2013 workflow.
So how do you build a workflow to take into account Skip to Stage logic?
Assume the following SPD workflow, it consists of three simple stages, each sequentially transitioning to one another. For each stage, there is a simple Log to workflow history list action, so we can see what the workflow is doing, and a Wait for the Project to be Submitted action (this stop the workflow executing and zooming through to the end).
In normal operation, when this workflow runs it will enter stage one, log ‘Stage 1’ to the workflow history list, and then pause waiting for the project to be submitted via PWA. Once submitted, it will move into the next stage, and so on, until it gets to the last stage, when on the final submit the workflow will complete.
If you try and restart this workflow via the Change / Restart Workflow feature, and choose to Skip the workflow on to Stage 3, you would logically expect the workflow to just kick off in Stage 3. However this is not the case, even though the new Workflow Manager workflows allow you to build workflows that jump back and forth, they are still sequential behind the scenes, meaning your workflow needs to start on Stage 1 and move through the various stages to get to Stage 3, including any logic that is defined.
In order to skip the logic, the secret is to use a new action in SharePoint Designer called ‘Include Stage’. When you add the ‘Include Stage’ action, you will see a step entitled ‘If Project Web App starts the workflow normally or restarts the workflow and includes this stage’ added to the designer. This step is the key for ensuring when a workflow is restarted using Change / Restart workflow.
So what you will see:
- If a workflow is stated normally, i.e. when creating a project, then the actions within will be run (in the example, the Wait for Event: When a project is submitted action)
- If the workflow is restarted using Change / Restart Workflow and the stage being evaluated is the one being skipped to, or follows it, then the actions within the step will be run.
- If the workflow is restarted using Change / Restart Workflow and the stage being evaluated is prior to the stage being skipped to, then the actions within the step will NOT be run.
It is important to remember that any other actions outside of the ‘Include Stage’ step will continue to be run, irrespective of whether the workflow was started normally or restarted.
So there you have it, if you’re going to be building demand management workflows using SPD, then best practice has to be to wrap all your business logic / approvals in one of these ‘Include Stage’ steps.
One final bit of info, the ‘Include Stage’ action also is available for use in the Transition section of the stages, meaning you can change the logic and flow of your workflows depending if the workflow was restarted or not. I am not going to dig into this too much now, but it is there.
Many thanks to John from the Project Product Team for his assistance with the above.