Building a Low-Code BPMN Workflow Platform

Context

At Sky I was UI Lead on a low-code network automation platform: a web app where engineers design automation workflows as diagrams, run them, and track each run through to completion. Several teams and external business partners used it. Under the hood, workflows were BPMN 2.0 models (the standard notation for business processes), executed by a workflow engine and a fleet of microservices.

Problem

The first generation of the UI had grown use case by use case. Each new automation brought its own screens and its own copy of similar logic. Editing workflows was fragile, permissions were enforced mostly in the browser, and onboarding a new use case meant a lot of bespoke code. The aim of the next generation was to make building a new automation mostly configuration: draw it, set its properties, publish it.

What I did

• Made the diagram model the source of truth. Instead of mirroring diagram state in a separate client store, every property edit went through the diagram library’s own modelling API and command stack. Undo/redo and change events came for free, and the model could never drift from what was on screen. Adding a new configurable property became a documented recipe: constants, a typed model per element type, serialisation, UI, tests.
• Debounced everything that touched the model. Every keystroke executed against the BPMN model, so inputs were debounced and showed clear “saving… saved” feedback. No intermediate save buttons.
• Moved permissions to the server. Role-based access was checked at route level and feature level (can you see this page; can you change this workflow), with the server as the authority and the UI only reflecting it. Client state can be altered, so it can’t be trusted for security.
• Versioned workflows by copying the whole folder, so relative references between files never needed rewriting. A boring decision that removed a whole class of bugs.
• Chose views carefully. A Kanban board of tasks was a view only. Assignment used explicit commands, because drag-and-drop couldn’t express “assign to this person or that group”.
• Generated forms from JSON Schema rather than hand-coding each task’s form, and pushed for a catalogue of reusable, tested building blocks (form snippets, named sub-workflows) so new use cases started from approved pieces.
• Hardened the codebase in parallel: TypeScript errors to zero (Driving a TypeScript Codebase to Zero Errors), a coverage drive with network-level mocks (A Testing Strategy Teams Actually Adopted), secret scanning, and an API gateway in front of the services (Rolling Out an API Gateway).

Outcome

The platform let the team offer automation tooling as a service to other teams and partners, and cut the engineering effort needed for routine work. That’s the CV-level summary, and it was the point of the whole thing. New use cases could be built largely from existing building blocks, and the documented recipes meant other developers could extend the editor without me in the room.

What I’d do again

• Let the domain library own the domain state. Fighting a mature modelling library with your own store is a losing battle.
• Put security on the server from day one. Retro-fitting it is much harder.
• Invest in reuse explicitly. A catalogue doesn’t appear by accident; someone has to curate it.

What I’d do differently

I’d have written the “how to add a property” recipe and the architecture overview much earlier, rather than near the end. Documentation written while the knowledge is fresh is cheaper and better. That lesson fed straight into Knowledge Transfer Before Moving On.

Related notes

Internal Developer Platform · Where Platforms Fit: DDD Subdomains · API Modelling · Bulletproof React · Zustand Transient Updates · AJAX Polling