Collaboration

SharePoint workflow, yes or no?

SharePoint 2010 ratchets functionality up a notch across the board. But if Workflow's your thing, you need to do a sanity check before pulling the trigger. Here's a template for that sanity check.

I've done three SharePoint consulting gigs for government agencies, and these days, they all seem to want the same thing: process automation, to make up for workforce attrition. The public yammers endlessly about reducing the size of government, but they want to do that without giving up services. And decision-makers in government have lately been looking to SharePoint for that automation.

We get into tricky territory here. Yes, SharePoint can streamline processes out of the box. Yes, SharePoint has workflow built in. Yes, this workflow is .NET-based, and extensible. But whether to rely on SharePoint, even in its 2010 incarnations, for your organization's workflow platform is far from a no-brainer.

Workflow, top-to-bottom

SharePoint's canned workflows are very good at what they do; the thing is, they don't do that much. They execute from top to bottom, in sequential steps. If you're creating a document for public consumption, and the steps are writing, reviewing, approving, and publishing - and it gets no more complicated than that - then SharePoint workflows will do the job, out of the box.

But what happens when your process is iterative? Suppose the content being created requires simultaneous review at multiple levels? That many rounds of revision are anticipated?

Then there's the problem of multiple versions of documents and multiple approvals. I saw lots of this in government, documents with their own lifecycles that required approval and presentation in various stages of development. SharePoint assumes a document is completed once, approved once, presented once. That's often the case, but when it's not - wow, the complexity piles up fast.

And if that isn't enough to send you running for cover, consider compliance issues (as many government agencies must). The requirements placed upon document management and approval by either government or industry regulatory practices are rigorous and complex. Workflows that accommodate such complex requirements must be incredibly robust.

At this point your process is no longer a clean series of sequential steps - it's a tangle of loops. And SharePoint doesn't do tangles of loops.

Ah, but while SharePoint can't, .NET can. Can your developers get you there?

If you build it, they will come

SharePoint is, as most Microsoft server products are, built out of the standard MS parts: .NET, SQL Server, web services, XML. And most competent .NET developers can put together a robust, flexible workflow from scratch. So it stands to reason that any shop with competent .NET development capacity can put together complex workflow that can be hosted in SharePoint. This turns out to be the case, and there are plenty of resources out there for the shop that has these skills and the need to go this direction.

But, consider: once you build it, you have to maintain it. Custom code tends to evolve, and so the expense will be on-going. Consider also that if you want to deploy complex workflow that is not just a one-off, but useful generally to a large number of users, you're looking at a lengthy design phase.

On top of this, there's no guarantee that your home-grown workflows will transition seamlessly when you implement the next SharePoint release - meaning you may end up rewriting the workflows.

At this point, you're looking at a third-party solution (and there are quite a few out there to choose from), and crunching the numbers. The third-party solution is likely to win; whatever the cost, the workflows will be generalized from the outset, and compatibility with the next release of SharePoint is foremost on the third party's mind.

This isn't to say that home-grown .NET workflow for SharePoint isn't the way to go. If you can handle 90 percent of your workflow needs with the out-of-the-box workflows, and only have a couple of complex workflows to think about, then you may well be better off rolling your own than shelling out big bucks for a third party solution. And it may, in these lean times, be better to leave process automation on the back burner for the time being. The point, in the end, is that workflow in a SharePoint environment is a complicated question. Think long and hard.

About

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

5 comments
elistutz
elistutz

PNMsoft Sequence is a workflow software that is built into SharePoint 2010 and 2013. It has more functionality that a simple workflow designer, such as advanced forms, integration wizards with other systems, and dashboard analytics. What we've found is that with basic workflow products you can't achieve the level of customization you need for a mid-sized or larger enterprise business application. Sequence has proved successful in filling that gap, and providing an enterprise SharePoint workflow solution for situations with more advanced requirements. Here is a tour of the software: http://www.pnmsoft.com/technology/workflow-software/

Barryherne
Barryherne

Sharepoint can be hard and not every process is so neat there. I would agree with the idea that a third-party solution may seem to be a way out. Luckily, there are companies that pay special attention to workflow automation e.g. Comindware Tracker (http://www.comindware.com/tracker/) which main goal is to automate business processes in various departments of the company e.g. IT, marketing, finance etc. I would never about the tool until we felt that our HR needs more automation to deal with the amount of work i.e. job vacancies, interviews, hiring and firing etc.So, there are ways to automate processes and to forget about clumsy and heavy SharePoint.

Besides, Comindware Tracker is integrated with SharePoint and  you can create a workflow with Comindware racker and import it to SharePoint and work there.

robo_dev
robo_dev

I have looked into SharePoint's workflow capabilities, and they look pretty neat, but 'out there' I've seen several companies using Integrify with SharePoint for workflow, since adding Integrify gives SP more features and is easier to use/deploy. For simple stuff, SharePoint can do that, but if the process is complex, and/or there are unique requirements for things like a customer portal, then it can get too complicated.

Editor's Picks