Insight from Agora Consultants

Workflows in PS2010 and PS2013

Beginning development on Project Server 2013 can be a challenge. There are many important differences between workflows in 2010 and 2013, the way they work, and how they are developed. This blog will focus on the differences.

SharePoint Designer

From a developer’s perspective there is really one massive difference which leads to all the others. Creation of Project Server workflows must be done in SharePoint Designer.

NOTE: I know that workflows can also be created in Visual Studio 2012, but this option will be abandoned next version. Also taking Project Online into account, SPD is the only way worth talking about.

This is a large step away from the Visual Studio workflows we have created in the past. No C# code, no customization, much less flexibility in terms of functionality. For Project Server 2010, the code behind a workflow could do anything: integrate with other systems, perform functions that were not out of the box etc. It gave us as developers a lot more freedom. SharePoint Designer certainly takes a lot of that away, but it’s not as bad as you think.

Creating workflows is much easier. Every action is drag and drop. You can pick the current stage from a list of existing stages on the server, add actions such as logging to history or creating a workflow approval, and then read the outcome of that approval to determine the next action to take.

All of this was certainly possible in Visual Studio for PS2010, but it is now much easier and it can completed in 15 minutes. Some promotional material goes so far as to say that business analysts and power users can create workflows without having to go to the developers. I disagree, because workflow logic is workflow logic regardless of the server version. Only a developer will understand the logic required to create a foolproof workflow. Does that sound biased enough?

Sequential vs. State Workflow

This is a big change but I think it is a welcome one. Sequential is forward only (PS2010), while state can jump from any stage to any stage (PS2013). This makes complex workflows that require looping back to previous stages much easier to create. An if statement like this:

Is much easier to create than a huge loop in PS2010 with flags and temporary variables. Going back to a previous stage is now a non-issue.

Email Notifications

On the bright side, adding an email has never been easier, drag and drop a Send Email activity and configure the recipient. There are even a variety of placeholders for built in and custom project server fields.

The email engine for workflows has been revamped for PS2013. Unfortunately, this means more complications for developers.

The first problem is that you cannot send emails to users outside of your organization, or users that are not valid SharePoint users in general. This is a big step back from PS2010 where the email account domain was not an issue. As a result, if you try to send an email to a user that is not in SharePoint, or a Hotmail account (for example) then the workflow will fail. The whole workflow will stop dead, not just that email, but the entire workflow. It will have to be restarted by an administrator.

It would be much better if the email didn’t send as opposed to shutting down the project’s lifecycle, but things like this are what you come to expect from PS2013 and online.

Project Server Groups

The good news is the workflow can read SharePoint groups, send emails to groups, and even assign Project Server workflow approvals to SharePoint groups. Below you can see how all groups are available for selection when selecting an email recipient:

That’s all great, but here is the problem: you cannot do anything with Project Server security groups. They are just not available in SharePoint designer or in the new oData and CSOM APIs. This means on sites with Project Server security enabled, admins will have to manage the PS groups (for security) and a matching SP group for the sake of notifications and approvals.

Brave New World

There are a few new limitations to get used to, but at the same time a lot of complex functionality in PS2010 can be replaced with a few clicks in SharePoint Designer. The simplicity behind creating workflow approvals and looping back does make our jobs as developers much easier. The new limitations will have to be addressed in a creative way. That’s what we do best.

Comments are closed