In his latest response in our ongoing discussion about the problems with workflow, James Robertson makes two excellent points:
- People often abuse “exception” or “fast track” workflows; and
- Flexibility in who performs a workflow step is often a key consideration in creating adaptable workflows
Regarding the abuse of exception workflows, this is sort of a damned-if-you-do-damned-if-you-don’t situation. At some clients content authors/content managers have considerable power with regard to how and when their content is published. When you automate the process, depending on the publishing scheme you’ve implemented (e.g., batch versus real-time), some of that power could be diminished. If you don’t implement exception-handling workflows you’ve decreased the service level and increased frustration.
One answer is to implement a “fast track” workflow that bypasses normal approval processes and goes straight to the public site. As James points out, this has the potential for abuse. I would like to think that abuse could be easily identified and dealt with.
This type of exception handling wouldn’t be appropriate in all situations. The higher the potential for abuse or exposure to risk due to the wrong thing getting fast tracked, the less you’d want to take this approach.
The second point James makes is that, often times, there are an exceedingly large number of factors that play into who should be involved in a particular workflow step. There are a couple of things you can do here. The workflow technology being used has got to allow for the programmatic determination of the workflow step performer (one or more specific individuals, groups, roles, etc). In my opinion, that’s table stakes for a usable workflow solution. Assuming that is the case and assuming the business rules are reasonable, you can programmatically determine the performer.
If the factors are so numerous or complex or subjective that the performer cannot easily be programmatically determined, the person who starts the workflow can be empowered to manually choose the performer. (Again, assuming the underlying workflow solution allows this, but this seems like a fundamental feature). I know there are business cases where letting someone pick who performs a task are simply out of the question, but it is something to consider.
If you can’t code it and you can’t trust the initiator to pick the performer then it certainly will be difficult to create a practical number of workflows to handle the process.