Workflow functional specifications design

A lot of times I get the workflow process requirements in a functional specifications document just with the “happy flow” and a lot of the tools of workflow process are not used. I think we should try to ask the right questions at the beginning to make workflow design as good as possible and reduce the chance we will have to rewrite the workflow template.

What to do when rejecting?

Rejection is most of the time forgotten when you receive the first draft of the workflow process. This has a lot of effect on how to design the workflow, for example:

• Send back to the initiator and continue from the same step can lead to a sub-workflow for single approve.
• Restart the approval process you can using one big loop with all the approvers one after the other is possible.
• Send one level back can lead to calculating the approvers in the beginning to a table and go up and down the index.

What to display to the user in the task? What dynamic columns to display?

This is the place where the workflow can be used best but a lot of times the original requirement is something like “do you approve X” and nothing more, but the workflow task should not only give the user the relevant data but even show warnings, for example “pay attention this is a sensitive material”. Also, the process of finding out what the user will what to see causes the process to change. In the process you might understand that an approver might not be needed in some cases and more approves needed in other cases.

How to find the approver?

As a workflow developer this might seem trivial to you, but remember that people outside the workflow usually do not have to deal with this question and this might have an effect on the implementation outside the workflow, like creating new purchasing groups of adding classification. also you should decide Whether or not to use HR organizational module in workflow rules?

What to do if an approver can’t be found?

Again, you usually get requirements thinking only on the “happy flow”. The workflow can go into error and this is not so bad as long as you don’t panic, monitor the workflow and fix the errors. Sometimes however master data which is used to determine the approver is missing for example: there are customer of group A & group B but some customers are not classified and the approver is found by the group. You will need to decide who will handle the missing data workflows, a team leader for example.

In some cases the key user requires such a complicated rule you can see right away that you are going to have a lot of missing approvers. What I usually do in this case, if I can’t convince them to simplify the rule, is add a check to see if the approvers will be found in the beginning of the workflow and if not send a task to the key user to fix the problem, after a little while (and a lot of errors) if there was no real need, requirements get simplified…

Do you allow forwarding? Do you allow substitution?

Substitution and forwarding are basic possibilities in the workflow but some tasks might be sensitive, for example HR tasks, others less, if you allow substitution and forwarding you might cause a task to be directed to the wrong person, if you don’t you limit the users options to redirect a task wrongly sent to them or take over a task when the approver is sick.

Can the process be approved outside of the workflow? What cancels the workflow?

If the process can continue without the approval or the approval is meaningless maybe you should consider the need for workflow: if the user can’t print the order until the workflow is approved you can be sure that the workflow will be used, if you can go around the workflow or nobody cares about the outcome then the workflow might not be used.  At least you will need to have a wait for the approval by at wait for event step, something I add a dummy step with the title “approved outside the workflow” just to show that in the log. The process can be sometimes canceled outside the workflow (most common reason – the document was deleted) this again should be monitored by waiting for a deleting event.

What to do with errors? Who will do the error handling?

In regular process this question is always answer by display it to the user, only in workflow this question is not so simple, this means that you have to think about error handling, besides receiving the error message and creating a task for error handling you might want to also filler the error messages to help your users understand the error. But who should receive the error message? the approver? the initiator of the workflow? or a professional person who has a better understanding of the process. For example if the CFO was the last approver of a large invoice he/she usually should not be the one to handle the problem if the period of the invoice was closed.  Even the question of what to do with the error can sometimes be answered with “nothing” for example when the error is because the process was approved outside the workflow but the workflow approval was continued you will want to close the workflow.

Do you check authorizations?

If you use a decision task to approve, and then do the actual approval by a background task, since wf-batch is doing the approval this means that authorization objects are not checked for the approving user. This issue should be addressed as early as possible to prevent arguments later. see for example My (workflow) troubles with authorizations

Do you need deadline monitoring?

Another commonly forgotten issue is deadline monitoring. Do users what to be reminded after a few days of workitems which are waiting? or possibly send a notification to the manager of the approver? Pay attention also to the factory calendar when sanding reminder, in most cases it is pointless to send a reminder after 3 days when those 3 days include a holiday or a weekend.

Another commonly forgotten option is that that workflow has starting deadlines a well, for example: an HR admin has to approve that a employee attended a course – you can use starting conditions to start the workitem a day after the course has ended, showing only the relevant workitems to the admin