SLA tracking on Camunda 8, before the deadline passes

A target is not a deadline you discover afterwards

Most teams have service levels: answer a claim within ten days, process a permit within the legal limit, admit a patient on the planned date. Many only find out they missed one when they run a report at the end of the month. By then the only thing left to do is explain.

SLA tracking is about the opposite: knowing, while a case is still running, that it is at risk.

Three levels of deadline

On a task. Camunda 8 user tasks can carry a due date and a follow-up date, set in the model or computed from process data. They tell the person, and the inbox, when this step must be done.

On a part of the process. A timer boundary event on a task or sub-process can fire when time runs out: escalate to a manager, send a reminder, take another path. This is the engine acting on a deadline.

On the whole case. The service level the client cares about is usually end to end: from submission to decision. No single task deadline captures it; it has to be tracked across the process.

Model what the engine must do

Use BPMN for deadlines that change the flow of the process: an escalation, a reminder, an automatic decision when nobody answers. Keep these few and clear; a diagram covered in timers is hard to read and harder to change.

Do not model every target as a timer. Targets you want to watch rather than act on automatically belong in tracking, not in the diagram.

Track what people must see

For the targets you watch, decide three things:

• The target: ten days from submission to decision, for example.
• The warning threshold: when a case should be flagged as at risk, say at eight days, so someone can still act.
• Who is told: the team holding the case, its manager, or both.

Then make the state visible where people work: late and at-risk tasks at the top of the inbox, cases at risk on a list, and breaches counted over time so you can tell whether things are improving.

Find out why cases are late

When a case breaches, look at where it spent its time. Often one step causes most delays: a review queue, an outside party, a hand-off between teams. A heatmap of step durations and a replay of the late cases show which.

Checklist

• End-to-end targets defined per workflow
• Warning thresholds set before the target, not at it
• Task due dates feeding the inbox order
• Timers only where the process must act
• Breaches counted over time and explained

In Bridge

For each workflow you set SLA targets; the SLA tracker warns at the threshold you set and flags cases at risk and in breach before a deadline turns into a complaint. In the task inbox, tasks sit in deadline lanes (Late, Due today, This week, To claim), so the most urgent work is always on top.

The heatmap shows which steps hold cases longest, token replay shows what happened to a late case step by step, and dashboards show durations over any time range.