Graph-based operational workflows
Visual workflows for field operations
A platform for authoring operational procedures as connected steps and making those workflows available to operators on Android devices.
Teams use the web editor to create operational procedures with steps, branches and loops. Those procedures are then followed on Android devices, so the editor and the device must interpret the same workflow consistently.
01 / The product
Create a procedure and carry it into the field
The web editor represents procedures as connected steps. A workflow can branch or repeat where the operational task requires it rather than being restricted to a fixed checklist.
The connected Android environment uses Realm local storage and introduces synchronization considerations. A procedure saved in the editor must retain its steps and transitions when loaded on a device.
02 / Graph model
Make the stored graph the execution model
A canvas can display convincing arrows even when the stored procedure contains missing targets or disconnected paths. If the editor and executor interpret different representations, a visually valid workflow may not run as its author expects.
I developed the workflow-building and traversal logic around a graph of steps and transitions. I treated the editor as a view of that model so the procedure retained its meaning when passed to the Android execution environment.
Branches and loops make the editor more useful, but also make validation harder. Identifiers, transition targets and entry and exit behavior must remain consistent in both the editor and the executor.
03 / Loops
Support intentional loops
Some procedures legitimately repeat until a condition changes. Rejecting every cycle would remove that capability, while following every edge without explicit semantics can trap traversal or the operator in endless repetition.
I treated cycles as a domain requirement rather than rejecting them automatically. The traversal work had to account for intentional repetition while keeping the meaning of transitions and exits explicit.
Loops require clear exit conditions. Self-loops, two-node cycles and disconnected branches are useful cases for checking traversal because they expose errors that a long, linear example can miss.
04 / Device storage
Carry workflows into Android execution
Android execution introduces local storage and imperfect connectivity. A procedure can be authored on the web and later consumed from device-held data, so the diagram alone cannot define the execution contract.
I considered the Android/Kotlin execution environment and Realm storage while developing the web workflow model. The steps and transitions needed to remain understandable after storage and transfer, not only while displayed in the editor.
Local storage introduces version and synchronization concerns. A partially updated definition must not leave steps pointing to missing or incompatible transitions.
Evidence & further reading