The first step in workflow design is to select and analyze the business process by taking into account the considerations listed above, as well as any other additional considerations the organization defines for its workflow designers. An example of a business process that will be used to demonstrate how this might be done is the Close Case business process.
At a high level, the Close Case business process closes a case and the case's associated records, including its case reviews, case referrals, and open case events. A closure communication is printed for the service supplier(s) for any case referrals. A closure communication is also printed for the primary client on the case. The case identifier (caseID) of the case being closed is required data to perform this business process.
At a lower level, this business process starts off with a series of steps which include checking case security and validations, updating the case header status to closed, setting the case status end date to the current date. There are then three new records inserted: a case status record, a case closure record, and a case event record. All of these steps can be identified as intrinsic to the Close Case business process. Note, however, without any one of these steps, either the data integrity for the case is compromised or the traceability of the attempt to close the case would be incomplete. As all of these steps are required and would be difficult to implement should the workflow fail, these steps should therefore not be moved to the workflow process.
The next step in the Close Case business process example is the reassessment of the case. This identifies any over or under payments, and as such, is intrinsic to the business process, as the case should not be closed if any over or under payments are found. Thus, the step should not be included in the workflow.
If the reassessment results in an over or under payment, the case owner is notified of the over or under payment, provided the case owner is not the user who is closing the case. As this step involves a notification based on a condition, this step may be configurable as part of the close case workflow.
If reassessment does not result in an over or under payment, the close case process continues. The system checks if there are any active case reviews and cancels them while notifying the case reviewers. The system checks if there are case reactivation events on the case and closes these events. The system checks if there are any active case referrals, it cancels them, and generates a communication to the service supplier(s) impacted by the canceled referrals. The system also prints a closure communication for the primary client of the case. All of these steps can be part of the workflow, and where relevant, notifications can be defined.
Note that the communications for the service supplier(s) and the closure communication for the primary client need to be manually put in an envelope and sent to the communication recipients. This is an additional step that might need to be added to the close case business process and would require a manual activity.
The final step in the close case business process is to determine if the case owner needs to be notified that the case is closed. This is only done if the user closing the case is not the case owner. This step can also be put into the workflow and the relevant notification defined.
In summary, there appears to be seven steps to be included in the workflow. A number of these steps will require notifications. Additionally, case and reassessment data are required.