Why do workflows across several systems break off?
As long as a case runs within a single system, its database ensures that it happens either completely or not at all. As soon as several systems are involved, this safeguard is missing: each system only confirms its own step.
A lot can happen in between: a system does not respond, the network drops, a server is restarted, an approval takes days. The case is then left half-finished – already booked in one system, not yet in the other.
Over time, typical workarounds emerge:
- scheduled jobs that work through lists at night and start over the next day after an error
- queues whose messages get lost or are processed twice
- status fields in databases that are corrected by hand when something gets stuck
- spreadsheets in which someone keeps track of what is still outstanding
What does durable execution change?
Durable execution runs the workflow as a program and saves where it stands after every step. If a server or a connected system fails, the workflow then resumes at the same point: without restarting from scratch and without duplicate bookings.
Waiting times become part of the workflow. A workflow can wait days for an approval or monitor a deadline for months, without a program having to run continuously or someone having to keep a list.
Temporal is a widely used open-source platform for this principle. The development team writes the business logic as ordinary code; Temporal takes care of state, retries and timing.
Which questions belong in the architecture?
Reliability does not come from a tool alone, but from decisions made before implementation:
| Question | What it is about |
|---|---|
| What is a step? | Every call to another system becomes a separate, retryable step. |
| What may be retried? | Steps must be built so that a retry does not trigger anything twice. |
| What happens in the event of a final error? | Steps already completed are compensated – for example, a reservation is cancelled if the payment fails. |
| How long may a step take? | Timeouts per step and per workflow prevent anything from getting stuck unnoticed. |
| Who intervenes? | Approvals, pauses and cancellations reach the running workflow as signals from outside. |
| How do we change the workflow later? | Versioning ensures that running workflows complete according to their previous logic. |
How does a workflow become traceable?
Durable execution keeps a history for every workflow: which step was started, retried and completed, and when. This makes it possible to show at any time where a case stands and what has happened to it.
For internal audit or a customer, business-level proof is usually needed as well – for example, a log per case with reason, approval and result. It is best planned as a separate step in the workflow from the outset.
Where do you start?
Ideally with a workflow that causes noticeable effort today: a lot of rework, missed deadlines or questions nobody can answer quickly. It can show what durable execution delivers – and whether it is worthwhile for further workflows.
- 1capture the workflow: steps, systems, deadlines, error cases and volumes
- 2estimate the weak points and their costs
- 3define the target picture and error handling
- 4start with one workflow – old and new running side by side for a while