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.
TechNet article about SharePoint Designer and Visual Studio Workflows
Andy Burns' Blog 
Thanks for the very useful post,
We want to design a workflow that can be started on multiple documents which is not possible using sharepoint workflow designer or Visual Studio workflows as you mentioned 🙂
would you suggest a BPM engine that we can use to enable us starting such workflows on MOSS ?
Thanks alot in advance,
Best Regards,
Areej
Well, workflows can be started against multiple documents – so I guess you’re saying that you need a design of workflow where one workflow instance can encompass multiple individual documents?
My current thinking on this is that this sort of functionality would be best implemented using a Site for each workflow instance – this would give the location for many documents to be saved to and worked with. Some third party products allow workflows to handle site lifecycle – K2 and Nintex can do this, I believe.
The only other alternative that strike me – don’t use workflow. You can support a business process in SharePoint using just views and statuses.
Thanks Andy for your reply,
I am not sure if i understand what you mean…
well …this is my case:-
we have a business entity (peice of information) that consists of multiple documents. we want to create an approval workflow for this type of information without approving each document separately.
it is like having “attachemnet” workflows. where multiple documents are attached to the workflow instance.
is this possible?
thanks alot in advance
Hmm. As I said, then you probably want a container for your documents, and your process to control that container. Something like a Document Workspace would be appropriate. To control creation/deletion/lifecycle of that site, though,would require a third party product of some kind.
You can’t have many documents ‘sharing’ a workflow in SharePoint’s Workflow functionality. A workflow has to belong to a single item.
Yup exactly, a workflow has to belong a single item in a list or a single document in a document library …
so what other third party products can give me such option?
Thanks a lot for all your help and support and feedback … I am really lost here and this functionality is a must 😦
Don’t really know, you’ll have to take a look around. As I say, K2 BlackPearl and Nintex both allow workflows to control site lifecycle, that’s where I’d start looking. I suspect that the main problem will be the cost, if it isn’t budgetted for.
Otherwise, if you’re stuck with SharePoint only, you could do something like:
– Have a ListItem with a URL field.
– When the ListItem is created, capture that event and create a folder in a document library somewhere.
– Store the URL to the folder in the URL field
– Attach your workflow to your ListItem
I’ve not tried that, but it might be worth a go at prototyping.
Thanks a lot for your quick responses,
i will try your idea using events … it seems it can be done in this way.
thanks so much for your great post, you saved me a lot of time
Andy,
I have created a task list in Sharepoint 3.0 to manage a large number of action items (100) for my office. I’m not a programmer or a developer. Now I want to create a custom workflow to send reminders periodically BEFORE an action is due and also periodically AFTER the items are OVERDUE. The 3-state workflow that comes with Sharepoint does NOT meet our needs at all. I was told that the type of workflow I need is called an “escalation” workflow–is that correct? Can this be done using Sharepoint Designer? I do not have Visual Studio. I have never used Designer nor have I had any training yet. I have used Sharepoint for a couple of years.
Other questions:
– We do not want our task list populated with any workflow progress items (“workflow initiated”, etc.) Is there a way to have those go somewhere else? a different list? a different view?
– Does sharepoint know when to start each stage of a workflow automatically once you set up the workflow, or will we have to manually change the status of an action item to initiate each stage (open, reminder, overdue…)?
What we would like the workflow to do is:
– at the halfway point between the date the action was assigned and the due date, generate the first email reminder automatically to the “assignee”.
– auto-generate the 2nd reminder approx. one week before due date
– auto-generate 1st Overdue reminder the day after the due date passes
– auto-generate 2nd Overdue reminder 2 weeks later
– auto-generate subsequent Overdue reminders every 2-3 weeks until the action is closed.
I would greatly appreciate any help/advice you can give me.
Hmm. What you really need is a full engagement with someone like the consultancy I work for, or for another professional services organisation.
There are a number of options for what you want, and we’ve implemented similar, bespoke solutions, but as you’ve identified, out-of-the-box SharePoint doesn’t do what you’re asking for.
An “escalation” workflow is just the generic business term for the process you’re trying to implement. It’s not related to SharePoint or the technology side of things. I don’t think SharePoint comes with an “escalation” workflow in the same way as it comes with a “three-stage approval” workflow.
What you’re looking to build probably requires Visual Studio, although I’m no expert with SharePoint designer – it may be possible that way. However, even building workflows in SharePoint designer quite a steep learning curve anyway.
All of which leads me back to my original thought – you really want to engage with a specialist third party, or start training up to do it yourself – and workflow is a bit painful.
I’m afraid (being one of them), I’m not quite sure how you set about finding a professional services group. If you have a local SharePoint User Group, it might be worth asking there – there are also usually a lot of freelance consultants who I’m sure would offer their services. Here in the UK our local group is http://suguk.org/
Or, actually, looking at your email address, would you have an internal IT team who might be able to assist? If you guys don’t have a strong IT team, nobody does!
Andy,
Thanks so much. Yes, we do have a great IT team, however, they are understaffed and underfunded at the moment, AND none of them have experience with workflows. I thought I’d try to figure it out on my own if I could. BUT–not being a developer myself, it is proving to be a little beyond me.
Could you answer the question about whether or not the workflow initiation notices that appear in the 3-state workflow can be sent to another list or location in sharepoint so that they do not “clutter up” the task list with additional information? We would still want to know if the workflow stages have been initiated, and what the progress is, we just don’t want them in the task list along with hundreds of tasks!! This is something we really want to know, because if you can’t, we may not want to use a workflow at all and just use “alerts” by manually changing the status.
Thanks, again!
Hmm. I’ve gotta admit, I don’t know – my experience with the out-of-box workflows is pretty limited! I tend to be more on the ‘writing custom workflows’ end of things (unless I can avoid it!)
I’ll take a look and get back to you.
Oh, and for what it’s worth, I am a developer and I feel that SharePoint workflows are beyond me sometimes (Damn InfoPath!)
Andy,
I’ve made a bit of progress building a custom workflow in sharepoint designer 2007 and have even gotten some guidance from our IT folks! However, I’m stuck on kind of a weird thing:
I’ve started creating a workflow attached to a task list. The first step includes an action to send an email message to the “assigned to” for a task. I’ve created a workflow lookup to look up the information in the “assigned to” column and send an email reminder–this step works.
When I created this step (Email this message), I clicked on “this message” and it brings up “define email message”.
In the “to” line, I clicked the “addressbook” icon
In the “select users” box, I clicked “workflow lookup…”
In “define workflow lookup” I selected “current item” as the source, and “assigned to” as the field
The action looked like this: Email test:Assigned To (“test” is the name of the task list)
I created subsequent email reminder steps and saved the workflow (it indicated no errors).
When I reopened the workflow later and wanted to create another email reminder action, I followed the same steps, but when I got to “define workflow lookup” and selected “current item” as the source, when I went to select “assigned to” for the field, it is not there among the options that can be selected.
Do you have any idea why this would happen?? I even tried creating an entirely new workflow attached to the same list (“test”) but the same thing happens…
HELP!
Hmm. You’re using SharePoint Designer? I don’t have a whole lot of experience building workflows in that, and the problem you’ve had isn’t one I’ve come across (in fact, I’m not sure I’ve ever sent emails from a SharePoint Designer workflow).
I guess one question is is the ‘Current Item’ the same item both times? I.e., is this an email reminder for another task step which has been created in the same way?
Andy,
I have created a workflow on a document library. This workflow creates several tasks inside a replicator activity. Now I have another workflow on the task list, that has to start off when a new task gets added to the task list. The 1st workflow works fine, the tasks get created (by default on the “Workflow Task” content type). But the problem is with the second workflow. It simply doesn’t start off at all. I thought maybe this has to do something with replicator, so had a simple workflow with a single create task. But even then my second workflow doesn’t start off. I am hopelessly trying out why the workflow does not get initiated at all.
Please can you help.
Thanks
I want to send all items in a task list in a mail at the end of the day according to a particular field in the item. Which feature of share point can be used to create this?