NASA’s Jet Propulsion Laboratory (JPL) needed to automate an internal document approval process where any given launch of the workflow could:
- Have unique and a varying number of approvers.
- Abort the approval process immediately upon a single approver rejecting, even if other approvers have approved or have yet to view the document.
- Re-route rejected documents to the initiator of the approval process.
- Upon all assigned approvers approving the document, route the document to completion, notifying stakeholders in the process.
Using Drupal and Nextide’s Maestro workflow module, JPL was able to prototype a base workflow template to automate their process. However, the missing element was the ability to implement a workflow that allows for on-the-fly selection of approvers, the number of approvers and managing the acceptance and rejection of the document.
Maestro supports the ability to assign a single unique instance of a task to one or more users dynamically. In this scenario a single task would be created with multiple users assigned to it, however, the first person to complete the task would complete it for everyone assigned. This produces a “one task, one user completes” scenario regardless of how many people were assigned to the task. JPL’s requirement was the need to assign a multiple number of unique instances of the same approval task to a set of users and continue the workflow past the multiple-assignee stage when all tasks are approved or a single task is rejected.
In a standard workflow template, the workflow administrator would logically build the template accounting for the tasks required and who is assigned to those tasks.
To illustrate the problem, Figure 1 shows a simple (and non-functional!) approval workflow template with four approvers. The template is like most other simple approval processes, however, JPL’s issue was that you never know how many approvers will be assigned to any given document. In the shaded area of Figure 1, you see four tasks: Approval 1 through 4. This is optimal if you always have four approvers. JPL required a dynamic number of approvers, each with their own task. What if there were five approvers required? What if there were three? Ten? The issue for this use-case is that dynamic assignments and rigid templates are not the answer.
Our solution was to get Maestro to spawn a variable number of sub-approval processes as required by the initiator. The parent process was able to spawn as many child approval processes as required, and each child was able to signal its completion, accepted or rejected status to the parent.
Figure 2 is an over-simplified representation of the workflow for JPL. The workflow template shows the parent process which is responsible for spawning the n-number of approval sub-flows and waiting for the sub-approval flows to be approved or rejected before continuing on.
Figure 3 illustrates how the parent process and the child communicate with each other using the Maestro API. The parent is able to spawn sub-flows, while the sub-flows are able to communicate their approval status back to the parent. The “Wait” task in the parent process is able to detect if all sub-flows are complete or if a sub-flow has signalled a rejection.
The workflows were put into production, successfully automating an internal business approval process for JPL. The shuffling of paper, sending manual emails to people, and the complete lack of visibility of where processes stall has been eliminated. Using our workflow as a base, JPL has automated a number of other internal processes. Letting Drupal manage the content and Maestro manage the business process has proven to be a success.