BPM tasks belong in your CRM, not in a separate panel
BPM engines ship with their own task lists and ready-made UIs. We embedded process tasks in the existing admin panel instead. Here is why — and what the first week after go-live taught us.
Every mature BPM engine has its own interface: a task list, forms, a process viewer. When we rolled out processes for a SaaS platform, we had it available from day one. We deliberately skipped it and built tasks into the admin panel the team was already using. Full UI integration took 9 days.
The thesis
A process that lives in a separate tool loses to a process that lives where people already work. Not because a separate panel is technically worse, but because every extra login, every extra tab and every context switch lowers the chance that a task gets done on time.
The arguments
One login, the same roles
In our implementation the BPM engine accepts the same JWTs as the admin panel and verifies them against the same public key. Panel roles map to candidate groups in the process. There is no second user base to sync, and no second place to revoke access when someone leaves.
Data context at hand
A "call the customer" task only makes sense alongside the customer's history: when they signed up, whether they used the service, which coupon they got last week. In the panel that context is one click away from the task. In a separate tool you would either copy it into process variables or make people switch between applications.
Forms from the process definition
The task form is not hard-coded in the UI. The panel reads fields from the process definition — type, label, required flag, allowed values — and renders the form dynamically. Adding a new process with new fields needs no frontend release. That keeps the biggest advantage of a separate BPM panel — flexibility — without its drawbacks.
Process visibility
Next to the task list we added a BPMN diagram view highlighting the step a given instance is on. The process files were written by hand without layout information, so the diagram is laid out automatically in the browser. For the sales team it answers "why did this customer get that message" without reading XML.
The security boundary
The admin panel and the customer portal use separate APIs — a deliberate decision made years ago, because mixing admin and customer APIs usually ends in security problems. Adding BPM kept that boundary: staff handle tasks through the admin panel, customers through their own API. The process engine is never exposed to customers directly. More on this in our piece on tasks completed by the customer.
What the first week taught us
The task list worked, the forms worked, processes created tasks as planned. And yet tasks sat untouched. The team simply did not visit the new page on their own — even inside a familiar panel.
We added three things:
- a redirect after sign-in to the task list when there are open tasks,
- a counter in the menu that refreshes automatically,
- a daily email about tasks open for more than a few days.
The lesson applies to every process rollout: technology is half the job. The other half is making sure the task finds the person.
When a separate panel does make sense
When processes span many systems and none of them is a natural "home" for users, or when an organisation runs dozens of processes with a dedicated team to operate them. In companies with one main working system — a CRM, an ERP, an admin panel — tasks should land right there.
The full project is described in A BPM engine embedded in an existing CRM.