...
- The details we are asking from the Requester are almost the same as those in the Simple Workflow tutorial. This time we decided to split Source Specification and Destination Specification into two fields and allow for the Requester to tell us that this is an URGENT request.
- The details of the request don't stop there. As the process moves along, we want the other responsible parties to add detail to the form.
- Once Desktop Services fields the request, we want to capture whether the firewall modification being requested is already in effect or not. Depending on the answer, the workflow will route the form to the appropriate party.
- If the Firewall Policy Group decides to disapprove the request, we want to capture their reason for doing so.
- If the request is URGENT, and the Firewall Gatekeeper already modified the firewall rules, and the Firewall Policy Group disapproved the request afterward, we want our workflow to automatically check a box that prompts the Firewall Gatekeeper to revert the modification.
The Workflow Diagram
Here is a workflow diagram based on our business process.
Let's lay down a few ground rules:
- Each violet element represents a node in the workflow.
- Each lavender quadrilateral represents a rule template that is applied to the node.
- Each blue diamond represents a routing decision made by the workflow engine. This does not necessarily correspond to a decision in our business process.
- The Request element is the start node in the workflow's route path.
- The Finish element means the workflow has ended without any disapprovals.
- We don't need to represent decisions for approval in the diagram, because at any point in the workflow where a Disapproval action is taken, the entire workflow is stopped (i.e. the workflow doesn't progress after any disapproval).
Request Work Groups
After going through the easy and expedient process of requesting Work Groups, the Kuali Rice administrator has notified us that the following groups are available for use in our workflow:
...