Key Decision Log (Workflow)
This document outlines key decisions made on the Workflow Building Block project, so that new contributors can understand the context and history.
Date | Decision |
---|---|
2021-10-22 | We decided to add a key decision log to capture the reasons behind key decisions made for future team members. |
2021-11-17 | We will use BPMN standard terminology, but we will not use tool-specific terminology to ensure that lots of workflow tools may satisfy this specification. |
| Each service may adopt one or more processes and subprocesses in a hierarchical tree, where each process may have a generic name by Govstack, suitable to maintain a library of processes. |
| The same processes may be called by different names based on local practices of a given jurisdiction (state/country). 2. User A knows that Limpopo Province MoH has a workflow engine with lots of cool processes. 3. User A browses existing processes provided by Limpopo Province MoH’s “workflow engine X” 4. User A clicks the “clone ‘new birth registration process’ button” and is prompted to SAVE AS “new Mpumalanga MoH birth process” in their Mpumalanga Camunda Cloud implementation. (Or whatever.) 5. User B does the same thing and clones it into their Free State MoH OpenFn deployment, saving it as “FS MoH Birth v3.0” |
| Have generic names for different processes (govstack defined), and also allow alias names for processes at various levels of a hierarchy(defined by govt). |
| Adopt a convention for process “types” or generic names, but users may name the processes they define in their Workflow implementation however they would like. We may ask that they adhere to a naming convention, but this does not belong in the BB specification. |
|
|
| Dropped “Complex Gateway” as it’s not recommended for use in Camunda or many other BPMN-based workflow applications. Everything we want in the use cases can be achieved with the currently described (4 other) gateway types. |