SharePoint Applied: Workflows in SharePoint 2013, Part 2

In my last CODE Magazine article, I professed my love for SharePoint 2013 style workflows. I must say, having been spurned by SharePoint 2010 style workflows, falling in love with a technology with the same name was not easy. In that article, I talked about how workflows can now finally scale and perform; I talked about how to setup workflows and how to use them in SharePoint designer. Microsoft introduced numerous enhancements in SharePoint designer 2013 surrounding workflows, but in this article, I wish to switch gears a bit and talk about the Visual Studio side of things.

However, before I dive into Visual Studio and workflows, you as the architect need to know of a few shortcomings of SharePoint 2013 style workflows.

SharePoint 2013 Style Workflows Gotchas

Do not be misled-I still love SharePoint 2013 style workflows, but as nice as this technology is, it does come with a few things you must consider:

• Licensing: SharePoint 2013 style workflows can be considered as SharePoint Designer and SharePoint itself as a client to workflow manager. You can write your own clients as well. For instance, a client that can run purely through the browser and allow the user to author workflows from an HTML-based user interface. Yes, it is possible to do that, and I anticipate some smart third-party company to jump on such an opportunity. However, out of the box, SharePoint 2013 Foundation has no story around SharePoint 2013 style workflows. You must use a paid version of SharePoint to create SharePoint Designer workflows that leverage SharePoint 2013 style workflows.
• Yet another Windows server: Yet another set of passwords to maintain, yet another server to patch, yet another SSL cert, yet another thing to configure, yet another hardware and software cost. You get my point.
• No tie in with content types: For the longest time we’ve created reusable workflows by tying them to a content type. SharePoint 2013 style workflows work at the item content type level. This is not such a bad thing, but it is a fundamental shift in how we think of content types. Associating workflows with content types and mostly re-associating those associations has always been problematic. We can effectively achieve the same thing by checking the characteristics of the item the workflow is running upon, and when a workflow is a part of an app, perhaps tying it to a specific content type is not very logical anyway.
• No upgrade path from SharePoint 2010 workflows: Other than a lame workflow bridge that lets you invoke the other workflow, there is no way you can migrate SharePoint 2010 workflows into SharePoint 2013 style workflows unless you rewrite them. This will probably annoy customers that have serious investments in SharePoint 2010 style workflows. It is worth noting that SharePoint 2010 style workflows will still work, as-is, in SharePoint 2013. They just won’t run as the much improved SharePoint 2013 style workflows.

Great! With the basics behind us, now let us dive into Visual Studio.

By: Sahil Malik

Sahil Malik is a Microsoft MVP, INETA speaker, a .NET author, consultant, and trainer, and a well-rounded overweight geek. He has a passion for SharePoint, data access, and application architecture.

Sahil loves interacting with fellow geeks in real time. His talks are full of humor and practical nuggets. His talks tend to get very highly charged, fast moving, and highly interactive.

You should check out his blog at http://blah.winsmarts.com

sahilmalik@gmail.com