Process Applications
Design Lead | Camunda
Making a whole automation one unit, tested and shipped together.
Camunda's tooling treated each automation as a single process. A real automation is many connected files, and users were already working around the gap. I led the design that turned the whole set into one unit, with testing and version control built in. This case study walks through the decisions that got there and what each one traded off.
What a process application is
A real automation is rarely one process. It is a set of connected files: the main process, the forms people fill in, the decision tables behind the logic, and more. A process application bundles all of that into one unit you build, test, and ship together. Think of a consumer loan: one entry process, plus the forms and decision rules it depends on.
A process application bundles everything an automation needs into a single unit.
My role
Design lead and IC across the initiative, in a triad with a product manager and a development team. Single IC and design lead for the Play test-scenario work. Design colleagues supported at times, the direction was mine throughout.
The problem
Camunda's tooling treated an automation as a single process. In practice it was many connected files, and users were already working around that.
Power users bundled their subprocesses and deployed them together, but only in the desktop tool built for technical users.
The web tool, the one meant for a broader, more collaborative audience, couldn't do it. Tracking data confirmed the pattern: files went out together constantly, just never supported as one thing.
So we asked the obvious question. Why are users doing this, and how do we make it real in the web tool.
Loose files that broke easily became one unit that ships whole or not at all.
Decision 1: make the bundle the unit
The two easy options were both dead ends. Wiring files together by hand was slow and broke easily. Deploying them one at a time changed nothing.
So the bundle became the unit.
We built an MVP and validated it with users before committing. A process application deploys all or nothing, which means a half-built release never reaches production.
That was a deliberate trade, safety over flexibility. And it created the next problem. If you ship the whole thing at once, you need a way to run the whole thing before you ship it.
The shipped product. One application, one deploy.
Decision 2: build testing into the flow
That became Play, a sandbox where you run a process without touching production.
Some customers already wrote tests in Gherkin. The principle was right, define your cases before you build the process. But interviews before we started building showed Gherkin was one layer too many for most users.
So I tied testing to something users already did.
You play your process through, and the run is saved as a reusable test scenario. One action, two results: you validate the flow, and you keep the test for next time.
It fit how business users actually work, get a rough process running, then record what good looks like. I led design for Play as the single IC from the point we decided users would author test scenarios inside it.
Play the process through, and the run becomes a test you keep.
Decision 3: version through Git, not our own system
Many people touch one process application, so everyone has to work off the same version.
We could have built our own versioning. We didn't. We saw that every customer was already on GitHub or GitLab, so we connected to that instead of competing with it.
It asks for a little Git knowledge, which a pure business user doesn't have. At the large customers that didn't matter, dedicated roles set the applications up. We designed for how the work was actually divided, not for an imagined user who does everything alone.
We connected to the Git tools customers already used, instead of building our own.
Outcome
Process applications, Play test scenarios, and Git sync all shipped and are in the product today. This is how Camunda customers build and run their automations now.