---
title: Workflow delays, reminders and escalations
description: "Illizeo does not measure an “SLA” in the sense of a promised turnaround. It does something else, and more useful: it **acts** when a request sits unanswered for too long. - **Reading time**4 min - **Level**Advanced - **Last updated**May 2026…"
url: "https://illizeo.com/en/centre-aide/measure-and-accelerate-workflow-slas/"
updated: "2026-09-21"
category: "Platform / Flows & approvals"
---

# Workflow delays, reminders and escalations

Illizeo does not measure an “SLA” in the sense of a promised turnaround. It does something else, and more useful: it **acts** when a request sits unanswered for too long.

- **Reading time**4 min
- **Level**Advanced
- **Last updated**May 2026
- **Module**Flows & approvals

## Step-by-step

1. ### Set the company-level delays

   These apply everywhere nothing more specific is set. Three switches govern the mechanisms: the deferred action, the reminders, and the escalation before the final decision.
2. ### Refine node by node if needed

   Each approval step in the builder carries its own delays: response, reminder, escalation. **The node overrides the company value** when it has one. It does not, however, control the switches: if reminders are off for the company, a reminder delay on a node does not turn them back on.
3. ### Choose the default action deliberately

   Auto-approve keeps things moving but loosens control; auto-reject protects but sends the requester back to the start; escalate hands the problem to someone who will answer. It is a governance choice, not a technical setting.
4. ### Read the workflow dashboard

   It gives volumes per category, open requests, recent activity and a completion rate — computed on the approvals actually running. A ranking of the approvers blocking the most requests is there too, but that one is fed by the graph engine: while approvals run on the historical circuit, the list stays empty.
5. ### Fix the circuit before shortening the delays

   A queue that drags almost always comes from one step too many, or the wrong approver. Shortening a delay only makes the default action fire sooner.

## Target SLAs by type

| Setting | Unit | What it triggers |
| --- | --- | --- |
| Response delay | Hours | When it runs out, the default action is applied to the untouched request |
| Default action | — | Approve, reject, or escalate — one choice per company |
| Automatic reminder | Days | A notification is resent to the approver who has not acted |
| Escalation before final decision | Days | The request moves to the approver’s manager, before the default action falls due |

## FAQ

   Are delays counted in working days?

No. They are counted in hours and calendar days. A 48-hour delay set on a Friday runs out on Sunday — bear that in mind when you set them.

   What if the approver is on leave?

The clock keeps running. Nothing suspends it automatically: it is up to the approver to set a delegation before leaving.

   Can reminders be switched off for a single step?

No. The step chooses *when*, the company decides *whether*.

   Does a superseded request still get the default action?

No. A request replaced by a newer version is excluded from the automatic pass.

   Does the requester see a promised turnaround?

No. They see the state of their request and who holds it, not a processing promise.

## What does not exist

No target SLA per object type and no “Flows → SLA” screen. No median, P90 or P99. No exclusion of weekends and public holidays. No account taken of the approver’s declared absences. No reminder thresholds at 50 % and 80 % of the delay.

### See Notifications and reminders

Learn to dose notifications without saturating.

[See all Platform articles](/en/centre-aide/?cat=platform)

### *Related*