Skipping stages with ‘Change / Restart Workflow’ in Project Server 2013 and Project Online & SharePoint Designer

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’.

Change Restart Workflows

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).

Example Workflow without skipping

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.

Skip to Stage logic

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.

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 nintex.com/project

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

Filtering Projects for Portfolio Selection

A question came up in the Project forums recently around how it was possible to filter the available projects for a portfolio analysis, so I thought I would post a little tip here, which from a majority of the Project Server 2010 implementations I have seen is usually forgotten or managed by business process.

When you create a portfolio analysis, Project Server allows you to choose which projects you want to use as part of the analysis, out of the box, this shows you all the projects currently within the PWA instance, irrespective of their status. This is fine, but can be confusing for end users who need to go in and manually pick out the projects they wish to include and can be prone to errors (you don’t want to include a project already selected in a project selection analysis again do you?).

Portfolio Selection - All Projects

Luckily the project selection component supports views. It’s tucked away in the top right hand corner but it’s there. Through the views we can choose to restrict the default view of the project selection dialog to show just those projects that are at a certain stage in the project lifecycle, for instance, ready for selection.

To configure the view, navigate to Server Settings > Manage Views and look for the Portfolio Analysis Project Selection views. By default Project Server creates a single Summary View. I would suggest leaving that view intact and create a new view that we will place a filter on, in this example I will call it the Projects for Select view. Within the view, choose the project custom fields you wish to have visible.

Configure the Project for Select view

 

In order to only show those projects at a certain stage, we need to add a filter to the view, to do this click on Filter and configure it as follows:

Configure the filter

In this example, the view will now filter for those projects that are in the workflow stage of 3. Select Checkpoint

Finally, assign the view security category as you would with other views and click on Save.

Select Projects - Filtered for correct stage

The new Portfolio Analysis Project Select view is now available to be used, ensuring only those projects that should be considered in the portfolio analysis are available.

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.

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.

image

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 http://bit.ly/pc332.

Adding Print capabilities to Project Detail Pages

A user in the Project Server forums asked a question this week about whether it was possible to add printing capability to the Project Detail Pages in order to allow the ‘forms’ to be printed out as there is no print button available on the ribbon.

Capture1

Out of the box, the printing capability in the Project Web Application is limited to the grids, including the schedule grids that are visible in a schedule PDP and uses a custom page to render the information as can be seen below.

Project Schedule PDP Grid Print

After a little experimenting with the Internet Explorer printing, it seems that PDP’s can be printed quite well directly from the browser, so I thought I would try and pull together a ribbon feature that enables PDP printing.

The feature consists of XML button definition and a little piece of JavaScript to determine if the button will be enabled or not. This is important so that the button can be disabled when the user is on the schedule page that has it’s own grid based printing function like the picture above. For the purposes of this feature, I have gone the quick route and do the check based on the name of the page, in this case if the page is called schedule.aspx the button will be disabled. You may need to modify this check if your schedule based PDP(s) have a different name.

Schedule PDP - Custom Print button disabled

The element.xml looks like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction Id="Ribbon.Tabs.PDP.Home.Print"
				  Location="CommandUI.Ribbon">
		<CommandUIExtension>
			<CommandUIDefinitions>
				<CommandUIDefinition Location="Ribbon.Tabs.PDP.Home.Groups._children">
					<Group Id="Ribbon.Tabs.PDP.Home.Print"
						   Sequence="60"
						   Description="Print Custom Group"
						   Title="Share"
						   Command="EnableCustomGroup"
						   Template="Ribbon.Templates.Flexible2">
						<Controls Id="Ribbon.Tabs.PDP.Home.Print.Controls">
							<Button Id="Ribbon.Tabs.PDP.Home.Print.PrintPDP"
									Sequence="40"
									Command="PrintPDP"
									Alt="Print"
									Image16by16="/_layouts/$Resources:core,Language;/images/ps16x16.png"
									Image16by16Top="-96"
									Image16by16Left="-160"
									Image32by32="/_layouts/$Resources:core,Language;/images/ps32x32.png"
									Image32by32Top="-288"
									Image32by32Left="-128"
									LabelText="Print"
									TemplateAlias="o1"
							        ToolTipTitle="Print"
									ToolTipDescription="Print the contents of the PDP"/>
						</Controls>
					</Group>
				</CommandUIDefinition>
				<CommandUIDefinition Location="Ribbon.Tabs.PDP.Home.Scaling._children">
					<MaxSize
						Id="Ribbon.Tabs.PDP.Home.Scaling.Print"
						Sequence="140"
						GroupId="Ribbon.Tabs.PDP.Home.Print"
						Size="LargeLarge"/>
				</CommandUIDefinition>
			</CommandUIDefinitions>
			<CommandUIHandlers>
				<CommandUIHandler Command="EnableCustomGroup"
								  CommandAction="javascript:return true;" />
				<CommandUIHandler Command="PrintPDP"
								  CommandAction="javascript:window.print();"
								  EnabledScript="javascript:
								  function disablePrintForSchedule() {
									var sPath = window.location.pathname;
									var sPage = sPath.substring(sPath.lastIndexOf('/') + 1);
									if (sPage.toLowerCase() == 'schedule.aspx')
									{
										return false;
									}
									else
									{
										return true;
									}
								   }
									disablePrintForSchedule();"
/>
			</CommandUIHandlers>
		</CommandUIExtension>
	</CustomAction>
</Elements>

The process of building the feature is exactly the same as outlined in http://epmsource.com/2011/12/13/hiding-disabling-ribbon-items-in-project-server-part-ii/ but substitute the above code into the Element.xml file and change the feature name accordingly.

Once the feature is deployed and activated a Print button should available on the PDP ribbon that when clicked will invoke the Internet Explorer print dialog.

PDP Print Button

From my preliminary testing, the output is pretty good, as can be seen from this ‘Print to XPS’ below:

XPS Printer Output

I have uploaded the full source to Skydrive which can be downloaded from the link below.

Project PDP Print Page

Happy PDP printing 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 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.

image

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.

image

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

Save the date: MPUG Melbourne Tuesday 24th May 2011

MPUG Logo

It’s that time again, after a break over the summer, I am pleased to announce that the next Microsoft Project User Group (MPUG) Melbourne chapter meeting is scheduled for Tuesday 24th May 2011 at Microsoft Melbourne.

The topic of this meeting is demand management, covering the theory behind it, how it can benefit your organisation and Project Server 2010’s approach to implementing this exciting new capability.

This is a free event, so save the date and make sure you register via EventBrite now! Smile