Trackline
How this differs from a BPM
A BPM models what happens inside your company, with people who answer to you. Here half the process is outside and does not.
**A BPM is very good at what it does: modelling a process with many branches, many roles and many systems, all inside your organisation.** Every participant has an account, an assigned task and a manager. The process moves because someone inside moves it.
Where the analogy breaks
| What is taken for granted | Internal process (BPM) | Collecting from third parties |
|---|---|---|
| Who performs the task | An employee | Someone at another company |
| Has an account and training | Yes | No, and never will |
| Can be assigned work | Yes | **No: they can be asked** |
| If they do not do it | Escalate to their manager | **There is nobody to escalate to** |
| The real bottleneck | Coordination across teams | **Silence from the other side** |
Important
**Modelling the external stretch in a BPM usually ends in a task called «wait for supplier document» that sits there for weeks.** The engine creates it, assigns it to someone inside, and waits. But that person does not have the document: all they can do is write an email and look again — exactly the manual work the BPM was meant to remove. The diagram is perfect and the process does not move.
What the outside stretch needs
When the BPM is the right tool
- 1
When the process is internal and branching
Approvals by amount, routing by department, integrations with several systems.
- 2
When the business rules are complex
Conditions, exceptions, internal deadlines. That is what a BPM is for.
- 3
And when they coexist, which is the usual case
The BPM runs the internal process and calls this one for the external stretch, via API.
Watch out
The honest comparison is not «one or the other» but **how much of the process is outside your control**. If it is small — one document at the end — the BPM can carry it. If it is half the process, across fifty companies with fifty ways of working, that half needs something else. And there is an easy signal: if your process has tasks sitting more than two weeks waiting on someone outside, that is the part being discussed.
Worth knowing
Setting this up needs no implementation project and no modelling: a template is defined in an afternoon and launched the same day. If your BPM is already running, the normal move is to leave it alone — the external stretch is added over the API and the internal diagram stays as it is.
›Does it replace our BPM?
No. It handles the stretch that leaves the company; the internal part stays where it is.
›Can they be connected?
Yes, over the API: the BPM launches the process and receives the result.
›What if our process is entirely internal?
Then the BPM is enough. This starts to pay off once third parties are involved.
A real case
The situation
A manufacturer models supplier onboarding in its BPM and the «receive documentation» task piles up 40 instances older than a month.
What you do
- Takes that task out of the BPM
- Replaces it with a call to the external process
- Lets the BPM wait for the result
What you get
The 40 stalled instances start being chased by the system, and the BPM is notified when documentation is complete.
The situation
A process team costs out modelling WhatsApp sending and a portal for unregistered users inside the BPM.
What you do
- Lists channel, identity and trail
- Compares with connecting over the API
- Presents both figures
What you get
The comparison stops being a matter of opinion: it is visible which part is worth building and which is not.
The situation
A company has purchase approval beautifully modelled in its BPM and wants to add supplier document onboarding.
What you do
- Leaves approval where it is
- Adds the documentation stretch as a prior step
- Connects the two over the API
What you get
Approval is untouched and stops starting with incomplete documentation.
The situation
A manager finds the BPM marks a process complete because someone manually closed the waiting task, with no document ever arriving.
What you do
- Removes the ability to close that step by hand
- Ties closure to the document actually arriving
- Reviews last quarter's closures
What you get
The cases closed without a document surface — exactly what the audit was going to find.
The situation
An organisation with no BPM considers buying one to solve subcontractor document collection.
What you do
- Separates which part is internal and which external
- Confirms nearly all the problem is outside
- Starts with the external stretch
What you get
The real problem is solved without opening an implementation project that would take months.
The situation
A BPM launches the document process over the API and needs to know when it is complete in order to continue.
What you do
- Launches the process from the BPM
- Listens for the completion notice
- Continues the internal flow
What you get
The internal process advances only when documentation genuinely exists, not when someone says so.
The situation
The quality team wants one dashboard for internal and external alike.
What you do
- Leaves internal metrics in the BPM
- Takes what is missing and since when from the external process
- Combines both in the report
What you get
The dashboard separates what jams inside from what jams outside — they are fixed in different ways.
The situation
A consultancy proposes modelling the entire process, third parties included, over a six-month project.
What you do
- Splits off the external stretch and runs it this week
- Measures what improves
- Decides later what still needs modelling
What you get
The painful part stops hurting while the decision about what deserves a project is made with data.
This article answers
- difference between a bpm and trackline
- we already have a process engine can we do it there
- modelling document requests in the bpm
- workflow for requesting supplier documentation