A BPM engine embedded in an existing CRM — in 9 days

The challenge

A SaaS platform serving customers in the US had a solid admin panel and CRM, but processes that take days or weeks happened outside the system. A new account with no activity, a long-standing customer who suddenly stopped using the service, a confirmation needed from the customer before a configuration change — each meant several steps spread over time, and remembering who should do what, and when.

The requirement was clear: processes should run automatically wherever possible, and people should get tasks where they already work. No separate tool that nobody would open.

The solution

We ran Flowable 7 as a separate service next to the existing system. Processes are modelled in BPMN, and automated steps call the platform's existing APIs — issuing a coupon, sending an email, checking whether the customer has started using the service. The source systems are unaware of the process engine; to them it is just another API client.

Four processes to start with:

• New account activation — an account inactive for a week receives an activation coupon. A week later the engine checks for conversion; if there is none, it sends an offer of help, and after another week creates a "call the customer" task for sales, with an expiry date.
• Churn detection — a statistical model judges whether a customer's silence is unusual for that particular customer, not against an average. Key accounts go to their account manager, who chooses the response; others receive an automated message. The process respects a cool-down period so the same customer is not chased every week.
• Customer confirmations — a generic pattern for a task completed by the customer: an email with a link, sign-in with the existing account, a form, a reminder, a time limit.
• Retiring a legacy integration — a process built on that pattern: the customer confirms readiness, the team gets a technical task.

UI integration

Human tasks appeared in the existing admin panel as a new section:

• a task list with claim, release and complete,
• forms generated from the process definition — a new process with new fields needs no frontend changes,
• a process diagram view highlighting the step a given instance is on,
• overdue signalling — after the first week it turned out the team did not open the task list on their own. We added a redirect after sign-in, a counter in the menu and a daily email about tasks open for more than a few days.

Authentication is shared: the BPM engine accepts the same tokens as the panel, with the same roles. Customers never connect to the engine directly — their tasks go through the customer API, which takes identity from the session.

The result

• 4 days from the first commit of application code to a production deployment on Kubernetes.
• 9 days to full integration with the panel: task list, forms, diagrams, notifications.
• The first nightly scan picked up dozens of customers for the activation process.
• The next process — customer confirmations — was added later as a short iteration, with no changes to the panel.

We describe two design decisions separately: why BPM tasks belong in the CRM, not in a separate panel, and how a customer completes a process task from an email link.