--- id: KB-TL-030 url: https://app.codecontract.io/help/trackline/how-this-differs-from-a-bpm idioma: en categoria: trackline subcategoria: empezar audiencia: usuario nivel: intermedio actualizado: 2026-08-23 tambienEn: [es] relacionados: [KB-TL-002, KB-TL-028, KB-TL-018] citadoPor: [KB-TL-014, KB-TL-029] --- # 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._ **Responde a:** 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 **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 **En corto** - **Reaching people where they answer**: email, WhatsApp, SMS, a call or a link, without making them register. - **Persistence owned by the system**, on its own schedule, not a task in somebody's inbox. - **Status that updates on receipt**, not when a person types it in. - **And a trail of who delivered what and when**, because that is what you will be asked later. ## 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. > [!WARNING] > 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. > [!NOTE] > 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. ## Ejemplos **A manufacturer models supplier onboarding in its BPM and the «receive documentation» task piles up 40 instances older than a month.** - Takes that task out of the BPM - Replaces it with a call to the external process - Lets the BPM wait for the result → The 40 stalled instances start being chased by the system, and the BPM is notified when documentation is complete. **A process team costs out modelling WhatsApp sending and a portal for unregistered users inside the BPM.** - Lists channel, identity and trail - Compares with connecting over the API - Presents both figures → The comparison stops being a matter of opinion: it is visible which part is worth building and which is not. **A company has purchase approval beautifully modelled in its BPM and wants to add supplier document onboarding.** - Leaves approval where it is - Adds the documentation stretch as a prior step - Connects the two over the API → Approval is untouched and stops starting with incomplete documentation. **A manager finds the BPM marks a process complete because someone manually closed the waiting task, with no document ever arriving.** - Removes the ability to close that step by hand - Ties closure to the document actually arriving - Reviews last quarter's closures → The cases closed without a document surface — exactly what the audit was going to find. **An organisation with no BPM considers buying one to solve subcontractor document collection.** - Separates which part is internal and which external - Confirms nearly all the problem is outside - Starts with the external stretch → The real problem is solved without opening an implementation project that would take months. **A BPM launches the document process over the API and needs to know when it is complete in order to continue.** - Launches the process from the BPM - Listens for the completion notice - Continues the internal flow → The internal process advances only when documentation genuinely exists, not when someone says so. **The quality team wants one dashboard for internal and external alike.** - Leaves internal metrics in the BPM - Takes what is missing and since when from the external process - Combines both in the report → The dashboard separates what jams inside from what jams outside — they are fixed in different ways. **A consultancy proposes modelling the entire process, third parties included, over a six-month project.** - Splits off the external stretch and runs it this week - Measures what improves - Decides later what still needs modelling → The painful part stops hurting while the decision about what deserves a project is made with data.