Building advanced Project Server workflows with Nintex Workflow for Project Server

Over the past week or two, Microsoft have been quietly uploading all the sessions from the recent Project Conference held in Phoenix to the Project channel on Microsoft Showcase. This morning the Project team officially announced the availability, so I am pleased to announce that the video of Mark McDermott’s and my session is now available for your viewing pleasure. I encourage you to watch it and let me know if you have any questions.


Finally, the session deck, including notes is available for download at

Project Conference Session Wrap Up

Today Mark McDermott and myself presented our session on Building advanced Project Server workflows with Nintex Workflow for Project Server. The session covered three main areas where organisations can leverage Nintex workflow within their Project Server environments.


Demand Management – During the session we looked at some of the more advanced scenarios for building demand management workflows, leveraging some of the Nintex out of the box actions such as state machines and flexi tasks. We also looked at using some of the new V2 features including the Query Project Data action that allows the workflow to query the PSI directly from within the workflow.

Event Driven – We introduced the new capability of Event Driven workflows allowing you to attach a Nintex workflow to a Project Server Server Side Event providing a huge array of new integration and extensibility options for your Project Server farm.

Project workspaces -Finally, we showed how workflow could be provided in project workspaces to support a project team with a number of activities including approvals, routing and custom notifications. We also showed how easily workflows could be extended to integrate with cloud based services such as Office 365.

Try it yourself

We wanted to make sure that you could try everything that we showed in the session yourself, so spent some time building up three detailed ‘how to’ guides each covering a different area. Links to these guides as well as further information on Nintex Workflow, Nintex Workflow for Project Server 2010 and how to obtain trial copies are available from

Building advanced Project Server workflows with Nintex Workflow for Project Server

Last week I was lucky enough to be interviewed by Dux Raymond Sy about my upcoming session at the Microsoft Project Conference which I will be presenting with Mark McDermott of Nintex. Mark and I have been busy putting the final touches to the presentation and demonstrations and have a really great session planned.

Our session is on Thursday 22nd March at 10:30am in room North 222 C. If can’t make it, or even if you can, make sure you follow the twitter hash tags #pc332 and #mspc12 to keep up with the action.

Less than a month until the Project Conference..

imageIt’s been a little quiet on the blog for the last couple of weeks, the reason is that I am head down preparing for my session at the upcoming Project Conference in Phoenix. I am presenting with the Vice President of Sales for Nintex, Mark McDermott on Building Advanced Project Server Workflows with Nintex Workflow for Project Server.

The session will go take you through some of the more advanced concepts with Nintex Workflow and how they can be related in your project server workflows, we will also be touching on some of the new components of version 2.0 of the product and how you can leverage them in your Project Server installation to improve project governance, delivery and accountability. 

For those of you that haven’t registered yet, what are you waiting for? There are over 90 sessions being delivered from a mix of partners, mvp’s, customers and the product team.  Registration is still open and available on the site.

If you are coming, our session is on Wednesday 21st, at 5:15pm, the last session before the party, so what better way to start your night at the Arizona Science Center than an hour of workflow immediately prior? Smile 

If you’re not coming, keep an eye on twitter for the hash tags #mspc12 and our session #PC332 for more links to great information.

Are you going to the Project Conference?

I'm speaking at Project Conference 2012In case you have been living under a rock, you may have missed some of the blog posts and buzz that is starting to build about the forthcoming Microsoft Project Conference, being held in Phoenix, Arizona, USA on the 19th through to the 22nd March 2012.

The full conference agenda has not been published yet, but at a high level covers:

  • 15 customer-led sessions (representing 6 verticals) where customers share personal success stories using Microsoft Project and Portfolio
    Management (PPM).
  • Project desktop best practices for scheduling, program management, Earned Value, and more.
  • Project Server best practices for Demand Management, Portfolio Analysis, Resource Management, Time Management, Business Intelligence, and more.
  • Key solutions overviews and case studies for Application
    Lifecycle Management, Innovation Process Management, Product Lifecycle Management, Dynamics AX integration, ERP integration, and more.
  • Technical best practices for IT Professionals and Developers.

Last week I was excited to find my session , ‘Building advanced Project Server workflows with Nintex Workflow for Project Server’ had been accepted. The sessions abstract is as follows:

Many organizations have used Nintex Workflow for Project Server to help them build their demand management workflows quickly and effectively. This session will show how your project management processes and governance can be implemented using demand management workflows, integrating workflows with Project Server event handlers and applying workflows in project team sites. We’ll also provide a few other tips and tricks on implementing these processes.

I have been hard at work with some awesome demonstrations that will show off the capabilities of Nintex Workflow for Project Server and am counting down the days to getting over to Phoenix and talking shop Smile

Nintex Workflow for Project Server V2.0 Beta First look

I know I promised no more Nintex posts for a while, but this week, Nintex announced the availability of the first beta of Nintex Workflow for Project Server 2.0, the latest version of the popular Nintex Workflow for Project Server product and I just had to post!

Version 2.0 provides a number of enhancements to the existing product, including the following changes to the demand management components:

  • Change Enterprise Project Type from within the workflow;
  • New Publish project workflow action – Provides the ability to publish the project that the workflow is associated with, ensuring that project information is kept up to date in the Published Database;
  • Query Project Server (also available in Site / List Workflows) – Provides a direct interface to PSI methods that query or read data from Project Server; and
  • Update project properties (also available in Site / List Workflows) – Update project properties using site and list workflows.

Query the Project Server PSI Workflow Action

If the ability to query the PSI from within the workflow wasn’t compelling enough, version 2.0 also boasts one other new feature, which I think will be a game changer, the ability to associate workflows to the Project Server Event Handler engine Smile .

Manage Event Driven Workflows

Through using these new Event Driven workflows it is now possible to create workflows and then associate them to the Event Handler engine within Project Server. Some of the uses that come to mind immediately including:

  • Create a simple audit workflow that logs who published, edited or updated a schedule to a SharePoint audit list;
  • Alerting the resource manager whenever one of their resources are added to a project schedule via a workflow task and alert;
  • Synchronising a lookup table with an external system, or a SharePoint list when the list is updated or checked in; and
  • Alert resource managers when new users are created in PS requiring an RBS to be assigned.

I have only had a couple of hours to play with the beta, but can already see some pretty compelling reasons and scenarios for use. Stay tuned for a couple of cool walk throughs in the coming weeks.

The Beta is available to all Nintex Partners.

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

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.

Using schedule data within a Nintex Workflow for Project Server workflow

Recently I have been looking into how far you can integrate a Nintex Workflow for Project Server workflow into the day to day management of a project. One particular area I have been concentrating on is encoded logic within the workflow to check the status of tasks within the schedule. Imagine the scenario, a project can only move into the close phase if all the deliverables or milestones in the project have been met, or you may want the phase of the project to change following the completion of a specific task.

In this post I am going to explore using Nintex Workflow for Project Server to query a project schedule to determine if all the milestones within the current phase have been completed before allowing the workflow to move forward.

The Schedule

In order for the workflow to determine which milestones belong to which phase, it is necessary to record the phase information against each task. To do this I have added a new Task custom field called ‘Task Stage’ and entered the relevant stage into it for each  task.

Project scheduled - Task Stage

The Workflow

For the workflow I am going to follow the same basic pattern used for the Stage Gate approval in this post, a variable controlled loop that will continue to repeat until a certain condition is met. Unlike the previous post, instead of a task being assigned to security group for approval, we are going to leverage another Nintex action, called Execute SQL.

Nintex Execute SQL Action

This action, in my opinion is one of the most underrated actions in the Nintex suite, usually because it’s only used to query non SharePoint data stores (remember direct SQL lookups against the ContentDB are not supported and shouldn’t be attempted). However as Project Server has it’s own dedicated Reporting database which contains a wealth of information about each project including the schedule that can be queried, we can leverage the Execute SQL action to our hearts content.

To start with, I am going to create the plumbing for the workflow, starting with setting up the initial stage (Execution) and logging some status information. Following this, the workflow variable that will control the loop is set to False (Phase Milestones Complete) and finally the loop action is added that is set to repeat whilst the Phase Milestones Complete variable is false.

Nintex Workflow - Initial plumbing

Inside the loop we need to add a few more actions, starting with the Wait for Submit action that holds the workflow until the Submit button on the ribbon is pressed and the Execute SQL action which is going to do the clever stuff.


To configure the Execute SQL action, firstly the connection string needs to be configured, in this case I have configured the action to look at the PWA_Reporting database using the contoso\administrator windows logon.

Execute SQL Settings

The core of the action is the SQL itself, which does a count of all records the current project that are:

  • Milestones (via the TaskIsMilestone flag);
  • 100% complete, and
  • in the current stage

and stores the result in the variable ‘Outstanding Milestone Count’.

The full SQL used is shown here:

select count(epmt.TaskUID) as [Outstanding Milestones] from MSP_EpmTask_UserView epmt
inner join MSP_EpmProject_UserView epmp on epmt.ProjectUID = epmp.ProjectUID
inner join MSP_EpmWorkflowStage epmws on epmt.[Task Stage] = epmws.StageName
where epmp.ProjectUID = '{Common:ProjectUID}'
and epmt.TaskIsMilestone = 1
and epmt.[TaskPercentCompleted] <> 100
and epmws.StageUID = '43A1EB7B-562D-42E8-9A96-88817EF74295'

You will notice that we leverage Nintex’s ‘Insert Reference’ capability to inject the ProjectUID directly into the query on line 4, also their is a GUID hardcoded into the query on line 7, in this case it’s the is the StageUID for the Execution phase, as determined by looking at the System Identification Data on the Execution stage page. Finally the query above joins the Task Stage to the Project Stages using the Stage name, so it’s imperative the stage names in the schedule match the stage names in the workflow.


When the SQL is run, if all the milestones for the current phase have been completed, the SQL Query will return 0, otherwise it will return the number outstanding.

The last part of the workflow uses a Set a Condition action that checks the number of outstanding milestones returned by the query and either breaks out of the loop if there are none, or loops again if there are one or more.

Nintex Workflow - Loop Actions

That’s really all there is to the workflow, hopefully the breakdown above was easy to follow, but in case it wasn’t I have published the full workflow image here for your viewing pleasure.

Running the workflow

To test the workflow, I have created a new EPT called ‘Milestone Test’ with two phases (Execution and Closure). To the workflow I uploaded the schedule from above as a template and associated it to the EPT so it would be created automatically.

Once the project has been created, the workflow will start and then wait until the submit button is pressed.

Initial workflow - Action History

Clicking on the submit button will cause the workflow to proceed and check the schedule.

Initial workflow - Action History - Wait for Submit

Notice the workflow has gone back to the Wait for Submit action again and noted that there are 2 milestones outstanding. Next open up the schedule via the Schedule PDP and set one of the milestones to 100% complete, then republish and submit once again.

Edit the schedule to be 100% complete

You can see that the outstanding milestone count has gone down to 1, but the workflow is still in the Execution phase. This is because we still have one milestone left to complete before we can move to the next stage.

1 stage milestone outstanding

Lastly, set the final milestone to be 100% complete and republish and resubmit. The workflow will detect there are no outstanding milestones for the phase from the SQL query and therefore allow the workflow to proceed through to the next stage.Workflow completed

As you can see the Execute SQL action is a very powerful action within the Nintex toolset and when coupled with the Project Server Reporting Database allows you to incorporate nearly any aspect of your Project Server data into your governance workflow. Now get coding

Stage gate approvals with Nintex Workflow for Project Server

A common request from people that develop workflows within Project Server is how to create a simple approval process for a project to transition a stage gate, so I thought I would write a blog post covering off how you can achieve it with Nintex Workflow for Project Server.

The stage gate logic I am going to use, is outlined in the flow chart below.

Stage Gate Approval Overview

The approval will give the user two options, either approve and move into the next stage of the project, or reject the approval and stay in Stage 1.

Before we get to the approval part, the workflow logic needs to set a few things up. The initial stage, some status information, and to populate a workflow variable with the project name (which we will use in the approval later on).


Stage Gate - Initial Stages

This workflow makes use of a number of variables to store information read from the project as well as variables about the state of the project.

Stage Gate - Workflow Variables

Next up, before we get into the rejection loop we are going to set the Stage Approval variable to ‘No’. This variable is important as when it is set to ‘Yes’ it will break out of the loop and continue into the next stage.

Stage Gate - Set Approval Variable


Once the variable is set, we can move into the loop.

Stage Gate - Loop


Setting the loop up is really simple, basically we want to ensure the loop continues to loop whilst the Stage Approval variable is equal to ‘No’.

Stage Gate - Configure Loop

Once we are in the loop the first action is to ‘Wait for a Submit’, this ensures that we only proceed to create an approval if the user has clicked on submit for the project. Next we read in the users we wish to send the approval to, in this case we are using the ‘Read Project Security Group’ action, set to read in the Project Server ‘Portfolio Managers’ group and to store the information in the Portfolio Managers variable.

Stage Gate - Security Group

In the example above, I have also included a ‘Set Status Information’ action to update the Status Information for the user and let them know that the workflow is ‘Waiting for Approval’.

Stage Gate - Set Status Information

Next we need to actually set up the task. In this example, I have used a Nintex Flexi Task, which has a number of advantages over a normal to-do task:

  • We can assign as many approval options as we want (not just two!!)
  • There is out of the box logic to collate the results (majority, first past the post etc)
  • It provides downstream options at design time for further actions Of course, just like a normal task list in Nintex, you also get the value of highly customised notifications, escalations, delegation and reminders all out of the box and really simple to configure.
    For our purposes, the flexi task will be configured to assign a task to the users we retrieved into the Portfolio Managers variable earlier.
    Stage Gate - Flexi Task
    You can also see that the Task name has been configured to create tasks named ‘Stage Gate Approval : <Project Name>’ using the Project Name we retrieved into a variable earlier on in the workflow. For this blog post, I am not going to set up the other options such as Reminders and Escalation.

Next we need to configure the various actions to perform depending on the outcome of the approval.


Stage Gate - Flexi Task Actions

As you can see above, if the task is approved, the Stage Approval variable is set to Yes, which causes the workflow to exit the loop, however if the task is rejected, the Status Information is updated to update All Approver Comments and the loop starts again, going back to wait for a Project submit.

Stage Gate - Set Approver Comments

Finally, all that is needed is to add the actions to set the next stage once we have exited the loop.

Stage Gate - Final Stage

As you could imagine, the whole workflow itself can get quite long, so to that end I have uploaded an image of the whole workflow which you can download here.

So what does it look like in action?

Once a project has been created that uses the workflow, a task will be created in the Project Server Workflow Tasks list for each of the users that are part of the Portfolio Managers group. As you can see in the screenshot below, the task follows the naming convention we set up above.

Stage Gate - Workflow Approvals

Clicking on the task will bring up the default flexi task approval box (for those of us a bit more adventurous this can be customised with InfoPath 2010 to make it look as sexy as you want).

Stage Gate - Task Approval


As you can see, the flexi task has automatically added links to the Workflow Status and Project Details pages so the reviewer can view the relevant information before they make a decision.

So as you can see, setting up a stage gate approval in NW4PS is pretty simple and this one took about five minutes to build from scratch. Of course if you are going to have many stage gate approvals you may want to consider moving the actions into an action set, or saving the approval as a snippit to make it easier to view and reuse. You could also look at extending the workflow to add some extra logic to handle those cases if the read security group action fails to determine any users, using a run if action. There are a wealth of possibilities, so get coding Smile

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