The customer as a process participant — BPM tasks from an email link
Some process steps can only be completed by the customer — confirm, accept, reply. Here is how to bring the customer into a BPM process without exposing the process engine and without tokens in links.
Business processes rarely stop at the company boundary. Before we switch off a legacy integration, the customer must confirm they have moved to the new one. Before terms change, the customer must accept them. Until now such steps lived outside the process: an email, a reply, a manual tick in the system, a reminder sent — or not — two weeks later.
We built the customer into the BPM process as a full participant. Below is the pattern we used and the security decisions behind it.
The flow
- The process reaches a step that needs the customer. The engine calls the platform API, which sends an email with a link.
- The link opens a page in the customer portal. If the customer is not signed in, they go through the regular sign-in and return to the same page.
- The page loads the task description and form fields — defined in the process, not in the UI code.
- The customer submits the form. The customer API forwards the answer to the process engine, which validates the fields and completes the task.
- If the customer does not respond, a timer in the process sends a reminder and opens a second task with a new deadline. When that expires, the process ends with a "not confirmed" status and the team is notified.
Security decisions
No token in the link
The simplest approach — a link with a one-time token that by itself authorises the task — is also the riskiest. Emails get forwarded, scanned by filters that open links, and sit in mailboxes for years. Our link contains only the process business key. On its own it authorises nothing.
Identity comes from the session, never from a parameter
The customer API takes the customer ID solely from the signed-in user's session. Even if someone swaps the key in the link, they cannot complete a task in someone else's process.
The customer never talks to the process engine
The BPM engine is not reachable by customers. Customer requests go through the customer API, which talks to the engine with a service token. That preserves the boundary we keep across the platform: admin and customer APIs are separate.
The engine checks task ownership
The process engine adds its own check: a customer task carries an owner marker, and the customer ID from the request is compared with a process variable. A missing instance or task returns 404, someone else's task returns 403. Two independent layers, each sufficient to block abuse on its own.
A general pattern, not a one-off
We started with one concrete case — a confirmation before retiring a legacy integration — but built it as a general primitive: a customer task with arbitrary fields, a reminder and a time limit. Further uses — accepting contract changes, consenting to an upgrade, answering a survey — are a new process definition, with no changes to the customer portal or the API.
Summary
A customer in a BPM process is not exotic; it is the missing piece of most service processes. The condition: design it as if the email link will end up in the wrong hands — because sooner or later it will.
Wider context: A BPM engine embedded in an existing CRM — in 9 days.