How an insurer rebuilt insurance platform modernisation on Temporal

The claim that goes missing when a system blinks

A claim is never a single action. It is a journey that runs for days or weeks, through intake, assessment, approvals, payment, correspondence and long stretches of waiting on people and systems outside the insurer. A mid-size Australian insurer processes thousands of these journeys at once, each at a different step, each depending on an assessor, a repairer, a bank or the claimant to do their part.

In a lot of older platforms that journey has no single home. It is stitched together from cron jobs, message queues and a great deal of hand-written code that tracks state, sets timeouts and retries failures. It works until something downstream is briefly unavailable. Then a step fails partway, the message is consumed but the next one never fires, and a claim sits in limbo with no record of where it had got to. Staff find it days later when the claimant rings to ask why nothing has happened.

The obligations do not pause while a claim is lost. The General Insurance Code of Practice sets timeframes for handling claims and for keeping claimants informed. APRA’s CPS 230 raises the bar on operational risk and the resilience of critical processes. The Privacy Act 1988 governs the claimant’s data throughout. A process that quietly drops claims and cannot say where any of them are is hard to run against those expectations and harder still to audit.

Why Temporal, and what sits around it

The fix is to stop treating a claim as a string of disconnected jobs and model the whole journey as one durable workflow. We headline these rebuilds on Temporal for that reason. Temporal is a durable workflow orchestration platform: it persists the state of a long-running process at every step, so the claim survives crashes, restarts, deploys and outages, and resumes exactly where it stopped.

Think about what that removes. With a queue-and-cron approach, engineers write retry loops, timeout handlers and reconciliation jobs by hand, in service after service, and still cannot point to one place that knows a claim is half-finished. Temporal makes the claim journey itself the unit of work. The code reads as a plain sequence of steps. Underneath, the engine records every event, retries failed steps automatically with backoff, and holds timers that can wait days for a third party without consuming resources. When a downstream system is down, the step simply retries until it returns, rather than the claim falling on the floor.

The supporting stack stays deliberately small. PostgreSQL is the persistence layer behind the workflow engine, the durable record of where every claim is and what has happened to it. Docker packages the workflow workers so the same definitions run identically across environments and scale out under load. Temporal carries the orchestration and the durability. PostgreSQL and Docker carry the state and the deployment around it.

We kept the claim logic inside the workflow rather than spread across the services it calls. That way the rules of the journey live in one reviewable place, and the assessment system, the payment gateway and the correspondence service stay simple things the workflow calls, not co-owners of the claim’s state.

Building it, and where it got hard

The technology was rarely the hard part. The friction lived in the old behaviour we were replacing, and one example stands in for the rest.

The original process lost work whenever a downstream system was briefly down. A payment service or an external repairer API would blink, a step would fail mid-flight, and the claim would stall with no record of where it had reached. Engineers had responded the only way they could, by hand-writing retry and timeout logic into every service, which meant the same fragile pattern repeated everywhere and no two services handled failure quite the same. The result was claims stuck in limbo and a codebase nobody trusted under load.

The fix was to model each claim as a durable Temporal workflow so its state is persisted and steps resume exactly where they left off. Automatic retries with backoff replaced the hand-written loops, so a flaky third party no longer stalls a claim, it just delays one step. Durable timers replaced the cron jobs that chased statutory follow-ups, so a Code of Practice deadline is a timer the workflow holds rather than a scheduled scan that can miss. And because Temporal keeps a full execution history of every step, the question “where is this claim and what has happened to it” became one query instead of a hunt through logs across several systems.

The migration itself needed care. We could not stop the business to switch platforms, so new claims were started on Temporal while existing ones drained on the old path, and we ran both side by side until the new workflows were proven on real volume. Idempotency was the other quiet hurdle. A step that might retry must not pay a claimant twice, so each external call was made safe to repeat, keyed so a retry recognises work already done. None of this is glamorous. All of it is the difference between a platform that drops claims and one that does not.

What changed

In a representative rebuild, claims stranded by a brief third-party outage fell close to nil, because steps now resume on their own instead of failing silently. The pile of hand-written retry, timeout and state-tracking code collapsed into the workflow definitions, cutting a large share of the bespoke plumbing engineers had to maintain and reason about. And the exact position of any claim, with its full step history, became queryable in seconds rather than reconstructed after the fact, which made statutory follow-ups and audits markedly easier.

These figures are illustrative. They describe the pattern we see rather than a published result for a named insurer. The shift is the point. A claim stops being a fragile chain that breaks when one link is briefly down and becomes a durable journey that survives outages and deploys, retries itself, and can always say where it is. That is what platform modernisation buys an insurer that a new dashboard never could.

Where this fits

Durable claims orchestration is one application of our Legacy System Migration service, built on Temporal, for the realities of Australian insurance. It suits a specific shape of problem well: a long-running, multi-step process that crosses systems you do not control and must never silently lose work. If your claims stall when a downstream system blinks, or nobody can say where a given claim actually is, the place to start is to map the claim lifecycle and decide which steps most need to survive an outage.