Checking out the new Workflow Health pages

Whilst looking into a workflow issue today on my Office 365 tenant, I noticed a new feature that appears to be quietly rolling out into Office 365, the Workflow Health screen. Dee over at DDLS also noticed it a few weeks back and blogged about it, but I thought I would dig in a little more.

From the surface it looks like the feature addresses some of the issues in Office 365 when the Workflow Manager instance your tenant is attached to is down or unavailable or you want to see aggregated status of workflows in a site or list without clicking into each workflow instance.

To access this Workflow Health screen click the link entitled Workflow Health next to the Workflow history view in your lists, libraries or site workflows and the Workflow Settings screens as highlighted below..

Workflow Health

In all cases, the link will take you to the Workflow Health page that provides an overview of all workflows in your site and the status of their associated instances.

Workflow Health Overview

What makes this feature even more useful is that you can see at a glance the status of each workflow and drill into specific details on the last update for each instance by clicking on the i icon for the status, instead of having to navigate to each individual workflow instance and that you would usually have to click on the little blue i icon to get as well as choosing to Resume, Suspend or Terminate all instances of that specific workflow.

Workflow Health Popup

Now all of this seems to be really easy to get to for SharePoint workflows, but if you want to access Project Online workflows it’s a little harder to more involved…

In PWA, click on the Settings icon to open the Site Settings and choose Workflow Settings

Project Online Site Settings

In the Workflow Settings page, there is a link for Workflow Health.Project Online Workflow Health

Clicking on the link will open the Workflow Health screen for the PWA site.

Project Online Workflow Health Overview

Now there doesn’t appear to be any direct way to get to the page from within Project Online, so other than the Project team adding some links in the PWA settings, adding the following link http://<TENANTNAME>/sites/<PWANAME>/_layouts/15/WorkflowServiceHealth.aspx to the quick links will do the trick.

Happy Workflow Monitoring Smile

Setting up a workflow proxy account in Project Server 2013

I’ve had a few comments through the blog on setting up a workflow proxy account in Project Server 2013, so I thought I would post something to take you through how to configure this.

The Workflow Proxy in Project Server 2013 is important if you intend to use the classic workflow engine (not Workflow Manager ) and will be the account that makes the PSI calls associated with the workflow. The account should be set up as part of your Project Server installation and is specified in the Plan for administrative and service accounts in Project Server 2013 documentation.

Products such as NW4PS, leverage the classic workflow engine,  so if this account is not set up correctly when the workflow calls the PSI it will fail with an error like in the screenshot below.


Luckily the solution is pretty easy, however, unlike Project Server 2010, where the option was under Server Settings > Project Workflow Settings, in Project Server 2013, the option has moved into Central Administration and is probably the main contributing factor to this being overlooked.

To configure the account, navigate to Central Administration and choose General Application Settings from the left hand menu

Manage PWA Settings

Click on Manage under PWA Settings and you will be taken to the management screen for the PWA instance (if there are more than one instance, you can choose which one in the top right hand corner.

Project Workflow Settings

On the Settings screen, choose Project Workflow Settings, you will then be presented with the option to enter the Workflow Proxy Account.

Configure the Workflow Proxy Account

All that’s remaining is to enter the account you’ve already set up for the workflow proxy in the correct format (don’t forget to use a claims format account if that’s how you’ve set up your Project Server farm).

Quick Post : Workflows not working on a PS2010 farm where the Web Front End Service is disabled

I thought I would post this little gem so I don’t forget it. Hopefully it will be of use to someone else as well.

In the last couple of weeks a few people have told me about issues they encountered running Project Server 2010 workflows on a farm where the web front-end service has been deactivated. Deactivating the service can make sense if you are configuring the farm for improved performance by removing the need to listen to and render pages, or when trying to reduce the attack surface (although this is a lesser concern).

Anyway, to cut a long story short, it seems that when you turn the services off, you need to tell Project Server that the service has been turned off and to update it’s workflow configuration settings.  Thanks to Sameh, one of the excellent support guys at Nintex who found the procedure hidden away in an MSDN article from August 2010  at

I haven’t had a chance to test if this on a Project Server 2013 farm using the SharePoint 2010 workflow engine, but I would imagine the same will apply.

Introducing Nintex Workflow for Project Server 2013

I try not to mix my day job at Nintex with my community work and the content on this site, but today I want to make an exception and share some news on one of the projects I have been working on for the past few months.

I am pleased to announce that we have shipped Nintex Workflow for Project Server 2013 (NW4PS), an update to the popular workflow product for Project Server 2013.

Nintex Workflow for Project Server 2013

NW4PS 2013 provides all the capabilities of the 2010 version for use within Project Server 2013, including:

  • Demand Management workflows– implement workflows that support your full project lifecycle, from creation, through selection, planning, execution and to closure, leveraging an array of actions, including Query Project Server (PSI data), Project Publish and Change EPT;
  • Event Driven workflows – associated workflows to over 115 different Project Server event handlers;
  • Collaboration workflows – build workflows to support project collaboration scenarios that can talk back directly into Project Server.

NW4PS 2013 provides a seamless upgrade experience from Nintex Workflow for Project Server 2010, allowing organisations to leverage the new Project Server 2013 capabilities and features without having to worry about rebuilding & refactoring workflows.

As you would expect, Nintex Workflow for Project Server 2013 is fully Project Server 2013 aware, supporting items such as the new security modes, claims and 2010 look and feel in project workspaces.

You can read more on Nintex Workflow for Project Server 2013 over at

Setting up your Workflow Proxy account for 2010 legacy workflows in Project Server 2013

Workflows in Project ServerYou may be aware that Project Server 2013 can now use demand management workflows built in SharePoint Designer and the new Azure based Workflow Manager. But you may not be aware that the old 2010 ‘legacy’ workflow capabilities are also still present and available for you to leverage.

This is particularly important for organisations that may be upgrading from Project Server 2010 and have invested in demand management workflows and do not want to redevelop or significantly refactor their workflows for Project Server 2013 and the new Workflow Manager.

However, in setting up my Project Server 2013 instance I ran into an issue where I couldn’t register the workflow proxy account details for my PWA instance in Central Administration with what seemed like the correct credentials, resulting in the following error:

The specified Workflow Proxy User Account does not exist

Why is this the case? Well, under the covers, SharePoint 2013 (and Project Server 2013) the default authentication mode has changed from classic to claims. In fact it’s no longer possible to create a claims web app via the GUI any more, only PowerShell. If you have a claims based web application hosting PWA, you need to enter the workflow proxy in claims format. So instead of a domain\username format credential, enter the account in the correct claims format i.e. i:0#.w|domain\username.

One other thing I wanted to share when looking at 2010 legacy workflows in Project Server 2013, they will log to the ULS as Legacy Workflow Infrastructure, instead of the usual Workflow Infrastructure, so make sure you are looking in the right place Smile

Collecting business requests in SharePoint and automatically pushing into Project Server

At SharePoint Saturday Toronto, I presented one of my favourite sessions on SharePoint Governance and Lifecycle Management using Project Server 2010, based on Christophe Fiessinger’s and Scott Jamison’s session from TechEd NA 2011. I’ve delivered this session three or four times now, showing how organisations can benefit from using Project Server to collect business requests and guiding them through a process to successfully collect information, objectively determine which project to implement and then assist in the implementation.

Each time I have delivered the session, I have been asked if there were ways to collect the initial business requests outside of Project Server, in a SharePoint list for instance, reducing the need to licence and more importantly train all users within an organisation that may wish to lodge a business request. So, for SharePoint Saturday Toronto I decided to implement an interface that allows the business requests to be created initially in a SharePoint list and then via a workflow pumped into Project Server for the Project Server governance process to be applied.



This post shows you how you can implement it too. For this example, I will be using Nintex for the workflow component (disclosure, I work for Nintex), but you could also use a SharePoint Designer built workflow with the Christian Glessner’s iLSP SharePoint Designer Add-ons and a little elbow grease.

At a high level the solution has three components:

  • A SharePoint list that will be used to capture the business request. The list should be configured to capture the relevant items for the business request. In this example, the list requests the project name and a description, but you could extend this to capture other information such as anticipated budget, business need etc;
  • A default Enterprise Project Type configured to use the SharePoint Governance and Lifecycle Management demand management workflow. This EPT should also have a default Project schedule template associated; and
  • A list workflow associated with the SharePoint list above that will be used to call the PSI to create the project.


The list

Configure a SharePoint list to capture the information you want to capture. In this example, I have only captured two fields, as the rest will be captured within Project Server.

Both fields are set to be mandatory and the title field has been set to enforce unique values.

SharePoint list columns



The Governance and Lifecycle Management white paper and databases guide you through the process of configuring a demand management workflow and EPT. For the list workflow to create a project automatically, it is essential to make sure this EPT is set as the ‘default’ and that a Project schedule template has been uploaded and associated with the EPT.

Before building the workflow, we need to know some information about the project schedule template, this will be used by the workflow to create the project. Each project template is stored within the DRAFT Project Server database and can be extracted with the following query:


Write down the PROJ_UID of the relevant record for the Project Template you associated with the default EPT.


The Workflow

The key component of the process is the workflow that will take the list item and create a project in Project Server. As I mentioned above, in this example I will use Nintex Workflow & Nintex Workflow for Project Server as it has Project Server specific actions, but you can achieve a similar outcome in SPD with a little more effort.

The workflow itself consists of only three actions, the first action ‘Call Web Service’ is used to call Project Server’s PSI and specifically the Project web service and the CreateProjectFromTemplate web method. This method creates a project within Project Server based on a specific project schedule template.

The action should be configured as below, ensuring you change the URL of the web service, credentials and Template GUID to match your environment.

Configure Call Web Service Action

The projectName field above is using the Title variable. A great thing about Nintex is that you have access to the list context information by clicking on the lookup icon as below:

Select item title

The final part of the configuration is to capture the UID of the project that is created. When CreateProjectFromTemplate is called, if the method is successful it will return the UID of the created project in an XML envelope.

The Call Web Service action can listen for the response and parse it. To do so, click on Specify Elements and then Select Element.

Web Service Output

A XML browser dialog will be displayed allowing you to select which item in the response to read, in this case we are interested in the CreateProjectFromTemplateResult, so select it and click on Apply.

Web Service Response

Choose to save the returned value into a variable called ProjectUID, this will be used later.

The second action is also a Call Web Service action, this time used to Publish the Project in Project Server, up until now our project has resided in the Draft database, performing this publish will make sure it is published and therefore visible in PWA.

Like the previous action, configure the web service to call the Project PSI server with the relevant URL and credentials.

Publish Project

For this action, choose the QueuePublish method. This method has different parameter requirements:

  • jobUid – A GUID used to identify the job, in this case use the inline function fn-NewGuid()
  • projectUID – the UID captured in the ProjectUID variable prior
  • fullPublish – true
  • WssURL – leave blank

Once these two actions are run, a project will be created in Project Server using the default EPT and schedule template, all that is needed to do is to copy the other fields from the list into the project custom field using the last action ‘Update Project Properties’ from Nintex Workflow for Project Server that provides a simple wrapper for updating project custom fields. If you decide to use SPD, you would need to perform a raw PSI call to update the property making sure you have created a valid XML message (Fiddler will be your friend here, but a word of warning, it is not simple).

Configure the action as shown below, ensuring you select Title from the lookup field for the Project Name and then choosing to update the WPROJ_DESCRIPTION field with a list lookup against our SharePoint list, the item we are starting the workflow against (our project idea) and relevant field (in this case the Project Description field).

Update Project Properties

If there were other fields you wished to push into Project Server, they can be chosen in the Project Property drop down.

Finally, configure the action to ‘Publish after update’ and to ‘Wait for job completion’.

The completed workflow should look like this:

Completed workflow

All that is needed to complete the workflow is to modify the workflow settings to allow it to be manually started, and to add it to the list item context menu as follows:

Configure workflow settings

Then publish the workflow and you’re ready to start pushing your project ideas from a SharePoint list into Project Server Smile

Of course, what I have shown you above is the tip of the iceberg, with a little more work you could:

  • extend the workflow to add in some approvals before the business request is pushed into Project Server, allowing people like team leads or managers that may not necessarily need access to Project Server to review, add additional information and approve or reject the request;
  • configure the demand management workflow to push updates about where the business request is back out to the SharePoint list; and
  • add additional fields to the list that are pushed through into Project Server custom fields at project creation time.

Project Server IE9 Jump Lists Revisited

A while back I wrote about how you could customise your Project Server instance to incorporate one of the great new features of Internet Explorer 9, Jump Lists. In the post we explored how through a little bit of JavaScript and a content editor web part a Project Server administrator could provide quick access to common links in PWA when a user pins the site.

As I had been spending a lot of time around demand management workflows recently, I started to wonder if it would be possible to incorporate workflow approval tasks onto an IE9 jump list. After a little experimenting, I am pleased to announce IE9 Jump Lists Version 2.0 Smile

What does it do?

Just like the previous release, V2 provides quick access to core Project Server functions for users that choose to pin the site to their Windows 7 taskbar. Unlike the previous version, it will also poll Project Server to see if any workflow approval tasks are outstanding for the current user, specifically any tasks that are not in the status of completed and add them to the pinned menu in a special ‘Workflow tasks’ area.

Workflow tasks in IE9 Jumplist

Clicking on an approval task form the jump list will open up the approval task within Project Server for the user to action the approval.

Clicking on a task will bring up the correct approval page

Finally, V2 will also notify the user via a handy notification icon to show when there are outstanding workflow approvals awaiting action.

Taskbar notification

To give you a more detailed example of what V2 can do, I have created a small screencast showing the major features.

How it works

The new version of the IE9 Jump lists leverages a fantastic jQuery library called Pinify that is designed to reduce the effort and time required to implement IE9 jump lists on a site as well as providing a number of additional capabilities including notifications, discoverability and thumbnails. In our particular case, I have leveraged pinify to provide the static jump list components and to provide the plumbing to display the dynamic workflow tasks and notifications.

The other main components of the solution are:

  • Leveraging the SPServices jQuery plugin to poll SharePoint to get the currently logged on user
  • Using SharePoint’s inbuilt REST interface to lists to poll the currently assigned Workflow tasks from the ProjectServerWorkflowTasks list
  • Parsing the returned results via JSON
  • And finally, displaying a notification to the user on the task bar when Workflow Approval tasks are outstanding.

I am not going to go into the specifics of the implementation in this post due to the solution being slightly more complex than its predecessor. Instead, I have wrapped the whole solution, associated graphics and JavaScript files into a simple to install SharePoint feature, the source of which and Visual Studio project is available to download from my Skydrive account. In order for you to use this yourself, all that is needed is to:

1. Ensure you have a Shared Documents document library in your PWA site

2. Open the ie9jumplist.js file in the solution and update the PWA URL and ProjectServerWorkflowTasks list id to match your environment

3. Compile, test, deploy and enjoy.

N.B. This code is provided as is. No warranty is provided. You are responsible for testing the solution prior to deployment. The author accepts no responsibility for anything that may happen as a result of installing and using this code, etc, etc.