转：SharePoint Workflow and when to use it…

SharePoint Workflow and when to use it…

When building SharePoint workflow solutions you need to be very careful in only using it for small, single document-centric processes, and you need to try to avoid the ‘pain points’. For processes that push the boundaries of what workflow can do, you should consider redesign of the solution to reduce the workflow element or alternative products.

In a collaboration and publishing system like SharePoint, some sort of support for standard business process is essential. SharePoint workflow supports that for simple processes, but it is not enterprise grade workflow (yet). Indeed, out of the box it doesn’t work (at least, not fully). I’ll explain some of the issues with SharePoint Workflow later, but first I want to describe what SharePoint workflow is.

What is SharePoint workflow?

SharePoint Workflow is NOT the Workflow Foundation. The workflow foundation is not a product; it is a specification for the components of a workflow system (e.g. ‘host’, ‘auditing’, ‘storage’). Components built to this specification should plug in and just work. The foundation itself doesn’t provide much by way of these components – it’s got a set of workflow ‘activities’ (e.g. ‘Conditional’, ‘Parallel’, ‘Code’ activities), but doesn’t even include a host, or any way of interacting with a user! You can’t just build a workflow with the Workflow Foundation – it’s just a foundation for building on.

SharePoint Workflow is a partial implementation of the Workflow Foundation. It provides things like a host, persistence service, very very basic auditing, etc.. However, you can’t plug in alternative components into this structure. For example, the auditing in SharePoint workflow is, frankly, bloody awful, but you can not plug in another Workflow Foundation compliant auditing module.

SharePoint Workflow provides interaction through InfoPath forms. InfoPath is intended to allow Power users to develop and maintain their own data capture forms, but as workflow development to the level of adding custom forms is actually a Developer task, it’s a pretty curious choice of technology. Anyway, Microsoft have really pushed InfoPath for User-Workflow interaction – it’s possible to write ASPX pages, but there is little documentation on this.
So what are the limitations of SharePoint Workflow?

Well, let’s break this into three parts – SharePoint Designer Workflows, Visual Studio Workflows and Both.

SharePoint Designer Workflows

Can not redeploy. Workflows designed using SharePoint Designer apply to a single site, and cannot be redeployed easily. (It is actually possible, but is a developer task.) Major limitation vs Visual Studio approach
Numerous limitations to the structure and flow of your workflow. Examples include not being able to update multiple items, or see if the value of a field has changed – see here for more details. Major limitation vs. Visual Studio approach
Simplistic ‘Outlook Rules’ approach to designing workflow logic. It works, but isn’t as flexible as Visual Studio.
No dynamic task assignment. No task assignment based on availability, current workload, round robin, etc.
No interaction with external systems. This has to be done as a development task.
Visual Studio Workflows

Developer Task. You need a developer to do this.
Awkward. The tools for developing workflows are still in their infancy. Debugging is particularly bad (read ‘effing painful’). Development of workflows is slow.
Aspects are still pretty much undocumented.
InfoPath and Workflow don’t really use the same data structures. Thus, data handling between them is awkward. Avoid Repeating Fields at all costs (e.g. lines on an invoice)
Both

Workflows are Document Centric. (Or more correctly, ListItem-centric). An item (usually a document) ‘owns’ a workflow. A Workflow does not ‘own’ or ‘hold’ document(s). There is no equivalent of a ‘Workflow Attachments’ folder as in some other products. It is possible to bind multiple documents together using a common piece of meta-data (e.g. ‘Case Reference’), but the viewing of the process’ documents is troublesome – and probably via search. And it is possible to have processes for multiple documents – by have a separate workflow for each document. Thus, if you business process contains, say, 5 documents, then you’d need 5 workflows. This will also cause havoc when you start planning reporting on the workflows. Try to avoid processes which contain multiple documents.
Documents can only have one of each workflow running against them.
Rubbish tracking and reporting. Events just get recorded into a ‘Workflow History’ list. This does not support reporting on very easily – certainly not like a database table.
Delay Steps do not work OOB. That’s right, you can’t build delay steps into your workflow without first installing a patch from MS Professional Services – one which we haven’t laid our mitts on yet. That’s right, bang go all of your escalation processes. Nobody would want to do that in a workflow, right?
No view over all Tasks in environment. Users can be shown a list of all tasks in a single Site Collection, but not all Site Collections.
Workflow host can’t be split of onto it’s own server. Or at least, I’ve never found a way. In systems with LOTS of workflows, this will impact performance.
SharePoint Workflow vs. K2 ‘Black Pearl’
Excellent blog posting here. Yes, it is from K2 – but it is accurate and balanced

We did an analysis of what K2 gives over SharePoint Designer workflow. Here are the bullet points:

A graphical workflow-design experience that is intuitive and easy to use for business users. MOSS provides an Outlook rules type approach.
The ability for multi-site actions, such as moving documents between MOSS sites or publishing list items to a different site. MOSS only allows same-site activities.
Escalation potential based on working hours, custom actions, calendars, out-of-office and presence. MOSS provides escalation on fixed timings.
Capacity for transactional communication with systems outside the MOSS environment. MOSS can read external systems but not update.
Dynamic task assignment, reassignment, and deletion capabilities Presence-based, round robin, skill or role-based task allocation options. MOSS task assignment is to individuals or groups.
A unified view of all tasks assigned to an individual across multiple sites and portals in the MOSS environment. MOSS provides no overall view of workflow items across sites.
Detailed auditing and dynamic, user-designed reporting capabilities
Scalable workflow execution that won’t affect the performance of the MOSS environment
Tools that enable the creation, configuration and population of sites, lists, libraries, records, and publishing pages in MOSS as a result of a business process
Most of these problems could be overcome by custom development – but that takes time and money. Particularly relevant are the auditing and reporting improvements, and visualisation of the workflow and tasks – these problems would take significant effort to overcome.

Conclusions

SharePoint Workflow is a typical Microsoft ‘Version 1’ release. As the cliché goes, Version 3 will be when it starts to really work. It’s not helped by the fact that InfoPath is only really Version 2. In fact don’t get me started on InfoPath’s usefulness in a workflow solution. Suffice to say, I’m thinking of a two-word phrase, and the second word is ‘awful’…

SharePoint Workflow does have a place – when the workflow is simple, and reporting and auditing requirements are minimal. If your requirements start to exceed that, then you need to scale back the requirements, look at other products, or pay for extensive (i.e. potentially risky) customisation.

It’s worth noting that I’ve focus on K2 a bit – mainly ‘cos we’ve worked with their stuff before at work – but there are other workflow products out there from the likes of Captaris, Skelta and Nintex. I can’t say that I’ve really gotten stuck into any of them, but some features look quite neat.