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

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.
	Move to a single OpenAPI spec. How we think about “adaptors” - if there is an “Adaptor BB”, any technology that implements this BB must facilitate: 7. Data format transformation 1. E.G.: Replacing keys in a JSON object, etc. 8. Data exchange protocol transformation 2. E.G.: An origin system requests to register a patient with POST-A but the destination system requires that we instead make GET-A1 and then POST-A2 to complete the request. 9. Calling external transformers 3. E.G.: Some data format transformation is required, but it is provided by an external API so we simply call that external API instead of managing the data formation transformation ourselves. (Consider HL7 FHIR.)
	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.