Camunda Workflow Toolkit
Bringing workflow design and operations directly into the product
My contribution
- Designed the frontend toolkit architecture
- Integrated the bpmn-js / Camunda Modeler components
- Created 20+ custom UI components and integrations
- Designed the workflow lifecycle experience (design & operation)
- Collaborated with the backend team to define APIs and contracts
- Implemented the monitoring interfaces for workflow instances and history
The opportunity
Camunda was already an important part of our backend architecture. It handled workflow orchestration and execution, but the user experience remained outside our product.
Users who needed to work with workflows would have to rely on Camunda's own administration interface or desktop BPMN tooling.
There was no immediate pain forcing us to solve this. Instead, I recognized an opportunity:
If workflows are a core capability of our product, why should users need to leave the product to manage them?
The goal was therefore not to replace Camunda.
It was to productize our existing Camunda capability.
What I built
I designed and implemented a production workflow toolkit that brought the main workflow lifecycle into the application.
Users could:
- View existing workflows
- Visually edit BPMN workflows
- Save and deploy workflows
- Publish and activate workflows
- Manage workflow versions
- Enable or disable workflows
- View workflow instances
- Monitor running instances
- Inspect failed instances
- View workflow history
- Manage workflow variables
The toolkit ultimately supported 10+ workflows and monitoring of thousands of workflow instances.
My role
I owned the frontend side of the initiative across three areas:
Frontend architecture
I designed how the workflow functionality would fit into the existing frontend architecture and how the different workflow capabilities would be organized.
UX/UI
I designed the experience around our existing product rather than simply exposing Camunda's interfaces.
Frontend implementation
I integrated the BPMN tooling, implemented the workflow management interfaces, and connected the frontend to the existing backend APIs.
The backend Camunda integration was owned by a dedicated backend team. I worked closely with that team to define the frontend requirements, API contracts, data requirements, and operations needed by the UI.
Making Camunda feel like part of our product
One of the central challenges was the BPMN editor.
We used bpmn-js / Camunda Modeler components as the foundation, but the default experience did not completely match our application's UX.
Instead of simply embedding the editor, I customized it to fit our product.
I created 20+ custom UI components and integrations around the BPMN experience to bring its interaction patterns closer to our existing product UX.
This included adapting the editor experience so users could work with BPMN without feeling like they had suddenly entered a separate application.
The principle was:
Use Camunda as the workflow engine, but make the experience belong to our product.
From workflow definition to workflow operation
Another important design consideration was that workflow management is more than BPMN editing.
The toolkit covered both sides of the workflow lifecycle.
Design
Create / Edit
↓
BPMN Editor
↓
Save
↓
Deploy
↓
Version
Operation
Workflow
↓
Instances
↓
Running / Completed / Failed
↓
History
↓
Variables / Details
This meant users could not only define workflows, but also understand what was happening with them after deployment.
Architecture
The integration followed the existing application architecture:
┌──────────────────────────────────────┐
│ Product UI │
│ │
│ Workflow Management │
│ BPMN Editor │
│ Versions │
│ Instances │
│ Monitoring │
│ History │
└──────────────────┬───────────────────┘
│
│ API
↓
┌──────────────────────────────────────┐
│ Backend │
│ │
│ Workflow APIs │
│ Camunda Integration │
│ Workflow Operations │
└──────────────────┬───────────────────┘
│
│
↓
┌──────────────────────────────────────┐
│ Camunda │
│ │
│ Workflow Engine │
│ BPMN Execution │
│ Workflow Instances │
└──────────────────────────────────────┘
I did not bypass the backend architecture by connecting the frontend directly to Camunda.
Instead, the frontend consumed the application's backend APIs, while collaborating with the backend team to ensure those APIs exposed the information and operations required by the user experience.
The engineering challenge
The difficult part was not simply putting a BPMN editor on a page.
The challenge was making a complex workflow engine understandable and usable inside an existing SaaS product.
There were several layers to solve:
Complex third-party UI
BPMN editing has significantly more complexity than a normal CRUD interface. The editor needed to coexist with our application's navigation, controls, design language, and interaction patterns.
Workflow lifecycle
Workflows have states, versions, deployments, activation status, and execution history. The UI needed to communicate these states clearly instead of presenting workflows as simple records.
Operational visibility
With thousands of workflow instances, monitoring could not simply be a list of executions. Users needed to distinguish between running, completed, failed, and historical executions and access the relevant information for each.
Cross-team API design
Because the backend implementation was owned by another team, frontend requirements had to be translated into concrete API contracts and data requirements. This made the project a collaboration between frontend architecture, UX, and backend architecture rather than an isolated frontend implementation.
Outcome
The result was a production workflow management capability integrated directly into the product.
The toolkit:
- Supports 10+ workflows
- Has monitored thousands of workflow instances
- Provides workflow design and management without requiring users to leave the application
- Replaces the need for Camunda tooling for the supported product workflows
- Integrates BPMN editing into the existing product UX
- Includes 20+ custom components/integrations designed to bridge Camunda's UX with our product's design language
More importantly, it turned an underlying infrastructure capability into a native product experience.
What this project demonstrates
Taking a technically powerful system and turning it into a product experience that users can actually understand and operate.
The challenge wasn't to reproduce Camunda.
It was to determine which parts of Camunda's capabilities our users needed, how those capabilities should behave inside our product, and how to integrate them without breaking the boundaries of the existing architecture.
That required thinking simultaneously about:
Architecture → UX → API contracts → third-party integration → implementation → operations
And that is what made this more than a frontend integration project.
What I learned
The biggest lesson wasn't about bpmn-js, APIs, or integration.
It was that user experience is as much an architectural concern as a design concern.
You cannot build a good user experience on top of a complex engine without a clean architectural boundary. If you allow the engine's internal complexities to leak into the presentation layer, the UI will eventually reflect that complexity, making it harder for users to understand and harder for developers to maintain.
What I would do differently today
If I were to start this project again, I would spend even more time aligning on the API contracts during the design phase.
Designing workflows and monitoring instances requires a lot of real-time communication between the frontend and the backend. Establishing precise schemas and testing mocks early in the process would have reduced integration friction and accelerated the development cycle even further.
Interested in working together?
If you're building a design system, structuring a shared frontend, or scaling a multi-product architecture — let's talk.
Get in touch