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