Using Skip to Stage with Nintex Workflow for Project Server

I recently had a customer ask me how to use the Skip to Stage functionality of Nintex Workflow for Project Server. Now I know I have done a few Nintex posts recently, but I promised them I would post this for the greater good of the EPM community Smile (and will lay off Nintex for the next few months).

In case your not aware, the Skip to Stage capability of Project Server allows an administrator to skip a workflow to a particular stage, usually as a result of modifying the existing workflow, or swapping to a different workflow and needing to skip over some of the business logic or steps.

Workflow - Stage to skip to

Sam Chung wrote an excellent blog post on this over at the Project Programmability blog back in February 2010, and the same concepts apply to Nintex. Consider the flow chart below which outlines a simple Project Server workflow scenario.

Project Server Workflow

Should the administrator wish to skip this workflow to the the execution stage, and skip the approval, it is not possible as the workflow has not been coded to allow it. This is where the Skip To Stage information comes into play. When an administrator chooses to skip to a specific stage using the Server Settings > Change or Restart a workflow, the workflow is initiated with two pieces of information:

  • the Skip To Stage parameter set to ‘True’;
  • the Stage UID of the desired stage to skip to is passed through.

In the workflow, if logic is added to check for this, then it is possible to bypass the business logic for the stage and skip over. The Project Server workflow engine is clever enough to determine if the stage being skipped to is the stage in the StageUID and will stop the skipping there (however the same caveats that apply for a Visual Studio workflow apply and if the required fields for a stage being skipped are not completed, the workflow won’t skip).

Project Server Workflow - Skip to stage


Now to incorporate this into a Nintex Workflow for Project Server couldn’t be simpler, all that is required is to use the ‘Set a condition’ action to do a check on the Skip To Stage context variable, and then branch to the approval / flexi task (as below) if the value is no, or to skip over the approval logic if the value is yes. In the screenshot below, I have also added a ‘Set Status Information’ so I can log to the workflow that the skip is happening.

Nintex - Set a condition


The Skip To Stage information is stored within the Workflow Context, so when setting up the ‘Set a Condition’ action, make sure you pick the Workflow Context.

Configure Action - Set a condition - Workflow Context

Finally, as mentioned in Sam’s original blog post, you need to ensure you have selected the Always Wait option in your Set Stage actions.

Configure Action - Set project stage

If you don’t do this, the workflow may continue to skip past the requested stage.


First look at Nintex Workflow for Project Server 2010

imageArguably one of the most exciting features in Project Server 2010 was demand management or project lifecycle management (PLM). What PLM provides is a set of tools within a Project Server 2010 instance to manage the whole project lifecycle, from the concept of project phases and stages, a mechanism to collect and display data as you move through the project and best of all, a workflow engine. Out of the box, the development of workflows for use in PLM can be quite arduous. Unlike the rest of SharePoint, workflows for PS2010 cannot be built with SharePoint Designer, instead organisations have two options:

  • Leverage the Dynamic Workflow Solution Starter, a Microsoft released tool that enables simple approval type linear workflows to be built from within a web page without any code; or
  • Get a .net developer to use Visual Studio 2010 to design, develop and test a bespoke workflow that meets all the organisational requirements.

However, there is a third option, enter Nintex Workflow for Project Server 2010 (NW4PS), an extension of the popular Nintex Workflow 2010 (NW2010) which brings a simplified drag and drop interface for building workflows and integration into the Project Server workflow components to users via the web browser.

So how does NW4PS stack up?


The installation of NW4PS is relatively painless and well documented. NW4PS requires two components to be installed, NW2010 which provides the base workflow functionality and NW4PS which provides the Project Server integration. Once installed and activated, two sections will be added to Central Administration where the various components of NW2010 and NW4PS can be configured.

Nintex Workflow - Central Admin

Additionally two new options will be added to the Site Actions menu to provide end user access into NW2010 and NW4PS features.

Nintex Workflow - Site Actions

Creating a Workflow

The true power of Nintex Workflow for Project Server is in the simplicity of creating workflows and this is evident in the workflow designer that uses a web based drag and drop interface to create workflows.

Nintex Workflow for Project Server - Design Surface

The left hand side of the screen provides a menu of actions that can be used within the workflow, each logically grouped and searchable. To use an action, simply drag and drop it onto the design surface.

Nintex Workflow for Project Server - Drag and Drop

Once on the design surface, each workflow action needs to be configured, allowing the user to set the various parameters using simple dialog boxes. As you can see in the diagram below, setting the project stage is as simple as selecting it from a combo box, instead of having to dig around for a stage GUID like you have to do with Visual Studio. In addition, if as you are building the workflow you realise you have forgotten a stage, a handy link is provided to enable you to create a new stage from within the tool.

Nintex Workflow - Set Project Stage

For the purpose of this post, I decided to develop a simple branching workflow that collected some information for a proposal, then performed a validation and either approved or rejected the proposal based on the a predefined value, the exact same branching workflow described in this MSDN article.

Nintex Workflow for Project Server - Branching Workflow

The whole process of creating the workflow by dragging and dropping the workflow actions on to the design surface, configuring each action and then saving the workflow took a little under five minutes to complete.

Deploying a workflow

imageWith Project Server workflows that are developed in Visual Studio, it is necessary to create a workflow solution package within VS2010 and then deploy the solution into Project Server. With Nintex, the process of deploying is as simple as clicking on the Publish button.

Once published, the workflow will be available in the EPT configuration screen to associate it with a specific Enterprise Project Type.

Nintex Workflow for Project Server - Site Workflow Association

Running a workflow

Running a NW4PS workflow is exactly the same as you would expect for a traditional Project Server workflow, simply create a new project of the configured EPT and the workflow will kick off. As you would expect, the Project Detail Page (PDP) infrastructure of Project Server will kick in and the various pages will be displayed as configured for the current stage. Similarly, the normal PDP workflow overview page will continue to show the status of the workflow in a table, however Nintex also provides a handy visualisation for the workflow which makes it simple to see where a particular project is in the workflow process.

Nintex Workflow for Project Server - Workflow Status

Ok, so what else can you do?

The true benefit of NW4PS other than the reduced time to develop and ease of deployment is the sheer number of preconfigured workflow actions you can draw onto make the workflow as functional as possible. Such scenarios as:

  • Sending weekly reminders to Project Managers to complete their status reports whilst the project is in execution;
  • Creating tasks within the project by using a workflow controlled PSI call;
  • Alerting stakeholders that are not users of PS via an email of upcoming tasks / milestones;
  • Performing queries against the PS Reporting Database and use the data returned within the workflow; and
  • Link document approval workflows into PS workflows, ensuring that documents are approved before the PS workflow progresses are all possible, really taking Project Server Project Lifecycle Management capabilities to the next level.

Disclosure: I am an employee of OBS, a member of the Nintex group. However, this did not inform this post, I really do think it’s a great product Smile

Improve document approvals with SharePoint workflows

imageA common problem I see again and again on projects is the drama involved in getting a project document reviewed and approved. Typically signing off a document confirms that the document contents is correct and has been accepted, this can have commercial implications or be a formal stage gate in the project management process. Many organisations use a manual approval process, sending copies of the document around by email, or worse a printed copy that jumps from in-tray to in-tray which is incredibly inefficient and is nearly impossible to track the progress of. Therefore, anything that can be done to streamline the approval process should be considered.

Enter another great feature of SharePoint, workflows. Through the use of workflows, the whole approval process can be automated, storing the document centrally in SharePoint and sending tasks and associated email alerts to the various approvers and tracking the status automatically.

In this post, I am going to demonstrate how easy it is to use this workflow capability, specifically by attaching a document approval workflow to a document library that will kick off whenever a user publishes a major version of a document.

The Prerequisites

Firstly, check that the out of the box Workflow Feature has been turned on for the site collection you will be working in via Site Collection Admin > Site Collection Features.

site collection feature

Secondly, check that the versioning for the document library is set up and set to Major / Minor versioning via the Library Settings > Versioning setting.


Set up the workflow

Choose the document library you want to add the workflow to and select ‘Add a Workflow’ from the  Workflow settings.

Workflow Options

Select which content types for the document library you want the workflow to be applied to, if you are unsure of the content type, choose All.

Workflow Content Type

SharePoint 2010 comes complete with a number of prebuilt workflows that users can choose from. Should these not meet your requirements, new workflows can easily be built using SharePoint Designer or Visual Studio.  Luckily Document approvals are one of the out of the box workflows available, so choose ‘Approval – SharePoint 2010’.

Document Approval - Major Version

Give the workflow a meaningful name in the name field which will be used to identify the workflow once it has been created. Workflows in SharePoint use Task lists to store the tasks assigned to people and also the workflow history, you have the option to choose which lists are used to store these tasks. Finally you need to decide on when the workflow will be started, in this example we are going to kick it off whenever a major version of the document is published, so choose the  ‘Start this workflow to approve publishing a major version of an item’ option.

Next you will need to set up the workflow settings, including:

  • who you want to approve the document;
  • whether you want the approvers to approve it sequentially or in parallel;
  • what information you want included in the task / email sent to them;
  • how long you want the task assigned to them to last (Duration); and
  • how you want the workflow to terminate.

completed workflow settings

Now the workflow has been set up and is ready to use.

Use the workflow

The workflow we added to the library will be kicked off when a user chooses to publish a major version of a document in the workflow enabled library.


The first step of the workflow will bring up a settings screen for the user to have a chance to update some the workflow settings like the approvers and text sent in the request.

Start Workflow

On clicking ‘Start’, the workflow will generate the relevant tasks and assign them to the approvers, in this example, Amy Strande first, then Dan Jump. Amy will be assigned a task and receive an email alert linking to the task, like the one below.

Workflow task

Notice that the workflow task include a link to the document to review and details from anyone that has been involved in prior steps of the workflow. Amy can then choose to Approve or Reject the task or a few other options including reassigning to another person if relevant.

    Once the task is approved, the next task will be generated, in this case for Dan Jump, as seen below.


Once Dan approves the task, the workflow will be completed and the document will be approved.

Approved Document

Of course the real benefit of the workflow is that you have an status screen trail that will show you the status of the workflow at any time and once it’s completed, a full audit trail of when a document is approved, by whom and when, giving you an electronic sign off record for the document as can be seen below.

Workflow Information 2

In addition, through the introduction of Visio Services in SharePoint 2010, the status of the workflow can also be seen visually which is a welcome addition.

Workflow Information 1


As you can see, the process of adding a workflow to a document library is incredibly simple to configure, and once in place makes the process of approving a document very simple and streamlined. Through the workflow status screen the status of the approval can be seen at a glance, seeing who has approved the document , and more importantly, who hasn’t looked at it yet.

I challenge you to implement document workflows on your next project and not see an improvement in sign off times!