What I have figured out is that the key to defining the workflow is a single spreadsheet table with the following columns:
- Trigger Event
- Responsible Actor
- Workflow Task
- Task Status
- Task Owner
- Input Documents
- Output Documents
And the next two columns start a "sub table", listing the things that the responsible actor must do. It may for example, transition one task to another state, AND create two new tasks. Each one of these gets a row. The action is usually create or transition, or create/transition, and the workflow task is one to be acted upon. Create is used to create a task that hasn't already existed. Transition is used to transition a task that already exists to a new state. Create/Transition is used when you don't know what the current status is for the task (it may not have been created yet, but it could exist). Task Status indicates what the final state is for the task that was acted upon. The task owner indicates who the task owner is. Tasks can be created by the task owner, but may also be created by other workflow participants. For example, in the workflow I'm looking at, one participant creates a Respond to Request task for each possible edge system that could respond, encouraging them to complete some activity. During these actions, input or output documents can be added to the workflow. Usually input documents are added during CREATE and IN_PROCESS states, and Output documents are added during IN_PROCESS, COMPLETE or FAILURE transitions. It isn't usually the case that an input is added at the end of the task. In some cases (although I haven't had to do this yet), the only action an actor may have is to add an input or output document to another task, and do nothing else.
An important step is that a notification should be given to the task owner and any expected actor who will be triggered by the state transition on the task. Thus, is the Referral Requester workflow participant has a trigger on Response COMPLETED, then when the Referral Responder workflow participant the Response task to COMPLETED, it should notify the Referral Requester. For this, I'm assuming that the DSUB transaction is used for notifications, and that the workflow participants are duly notified by some other actor (perhaps the Workflow Manager) of these cases. There's no real subscription to set up, its just assumed that the notification transaction will occur under the appropriate cases. When you use a Workflow Manager actor (as I did in my definition), one thing that you could do is make sure that
- It is listed as the intended recipient of the workflow document (meaning that it will be managing the workflow),
- Some system, such as the registry or repository, interprets the intendedRecipient metadata in the provide and register transaction as a signal that a DSUB style notification should be given to the actor identified (in some way) in the Intended Recipient metadata.
- That workflow manager notifies any task owner of transitions that have occured on a task that were NOT performed by the task owner itself. For example, task creations, FAILURE or COMPLETION transitions that may be caused by other external events, et cetera.
- That workflow manager also notifies any actor responsible for activity on a trigger event that it can detect, e.g., a transition of a task.
An important point in building these tables is that you have to consider that the state of the workflow should be transparent to an outside reviewer that does NOT have any understanding of the internal business rules associated with the workflow. So, while you might assume that since a request has been completed, it is expected that the Referral Responder actors might be tasked with generating a respond, you wouldn't be able to tell if a task didn't exist for those actors. Thus, some tasks that don't exactly need to be recorded in the workflow document to manage the state among the workflow participants still need to be made explicit so that others (such as dashboarding applications), can still provide a good indication to an outside viewer what the status of the workflow is.
I've transposed an short example of the table below (because I usually make it horizontal rather than vertically oriented). I'll explain the key points after the table. This is an example meant to illustrate different features of the table, it's not the actual workflow that I wound up defining.
|Metadata\Trigger Event||Referral needed||Referral Request IN_PROGRESS||Referral Response READY||Referral Response COMPLETED -or- FAILURE|
|Responsible Actor||Referral Requester||Workflow Manager||Referral Responder||Workflow Manager|
|Referral can be accepted||Referral cannot be accepted||Acceptable Response available||No acceptable response available and more responses expected||No acceptable responses available and no more responses expected|
|Workflow Task||Referral Request||Dispatch Referral||Referral Response||Referral Response||Referral Request|
|Task Owner||Referral Requester||Workflow Manager||Referral Responder||Referral Responder||Referral Requester|
|Input Documents||Request for Referral|
|Request for Referral||Request for Referral||Request for Referral||Request for Referral||Request for Referral|
Referral Response (Required)
|Referral Response (Optional)||Referral Response (Required)||N/A||Referral Responses (Optional)|
|Notify||Workflow Manager||Referral Requester||Referral Responder||Workflow Manager||Referral Requester|
|Notes||This task is created for each possible referral responder.||Normal Completion||Wait, hopefully someone will respond positively||Nobody responded positively, include all negative responses as output to allow manual review/escalation.|
The idea of this workflow is to handle a managed referral request process, where there is a single requestor, and multiple possible referral responders. There's a workflow manager participant that handles the business processing of the responses to choose among acceptable responses. When an acceptable response is received, the referral request task is considered to be completed. There are a lot of different ways to extend this workflow by adding new columns to it. For example, you could be nice, and transition each outstanding referral response task to the FAILURE state once a referral response has been accepted, so that the Referral Responders can now ignore these tasks if it hasn't gotten to them. You could also add a time out event to allow the Workflow Manager to renotify Responders of tasks that they haven't paid attention to, or escalate the request, et cetera.
Getting to Other Views
Having developed this table, there are now a couple of different things that you can do with it. Often you need to explain multiple viewpoints of the workflow definition to satisfy to all and sundry stakeholders what is happening. The table allows me to generate three different views:
BPMNYou can start to diagram the workflow in BPMN. The general rules I've been following is that each workflow task becomes a task or activity in the BPMN diagram, and that each workflow participant (aka actor or task owner) gets a swim lane or pool. Conditions are used as conditional entry points into a task. Input and output documents are often included as components of the messages passed between tasks in different lanes/pools.
In an ideal world, I'd have the time to do some automation with a modeling tool so that I could graphically create the content in BPMN and subsequently generate the table, or import the table from a spreadsheet, and dynamically generate the diagram. For now, I can live with managing the diagram separately from the table and going back and forth between the two. It's just simply a matter of time and priorities.
Actor RequirementsWhen you sort this table by responsible actors and task sequence (effectively time), you get a description of the responsible actors view of the task to be performed, and what their required behaviors are.
Task oriented ViewWhen you sort it through by workflow task and task sequence, you get a view of the steps of the workflow.
Generalizing and SpecializingThe beauty of this table format is that it also allowed me to build more complex workflows by specializing from simpler ones, again by adding columns (rows really in my spreadsheet). In my case though, what we wound up doing was defining the most complicated workflow, and then removing columns (generalizing) to get to simpler ones. It doesn't really matter the direction that you do it in, what matters is that you can simplify or generalize these behaviors.
Notification (ala DSUB) is an important component of this workflow description, and the mechanism I've used is pretty straightforward. I'm not sure if that's something to submit as a modification to the XDW profile (e.g., the Notification option), or in a specific workflow profile, but I think it is probably worthwhile to consider.