No case sits idle without somebody knowing.
SLAs, timeouts and step-based escalation with notifications that reach the right person at the right time, without flooding anyone.
- For
- Management
- Operator
- Process owner
The problem
Stalled cases are discovered when the customer calls. Existing alerts are all or nothing: either they do not arrive, or they arrive to everyone, at any hour, until they become noise and get ignored. And nobody knows whether someone has really taken charge of the problem. An alert nobody confirms having read may as well never have existed, and one that reaches the whole department at three in the morning only teaches people to mute notifications. To work, escalation needs reasoned steps, suitable channels, respectful hours and clear proof that someone took responsibility. FlowSharp gives each of these a configurable, traced form.
3-step policy
- T+0 · in-app to assignee
- T+4h · email to manager
- T+1d · webhook to operations channel
Status
- Outside window: sent at 08:00
- Acknowledged by Marco · 12 min
How it works
- 1
Define timings and SLAs
Per-stage timeouts with readable durations (2h, 1d, 1w), flow SLAs and exception stages (Escalation, Expired, Out of capacity) reachable only by the system. Durations are written the way you would say them aloud.
- 2
Choose the reaction
Warning only to the assignee (or to Admins), or automatic move to the escalation stage. The process can therefore simply flag the problem, or change course on its own when time has run out.
- 3
Build the alert policy
Timed steps via email, webhook or event, as the organization's default rule or dedicated to the flow. Each step has its own channel and recipient, so that severity grows with time.
- 4
Someone takes charge
The recipient clicks a one-time acknowledgement link. Admins see acknowledgement and resolution times. The alert stops being a message thrown into the void and becomes a measurable commitment.
Specifications
| Channels | email, HMAC-SHA256 signed webhook, event, in-app |
|---|---|
| Anti-noise | per-recipient digest, time windows with time zone and daylight saving |
| Outside the window | email and webhook are deferred; in-app stays immediate |
| Acknowledgement | expiring one-time link, with an explicit click |
| Durations | up to 366 days; also from an expression or variable |
| Special alerts | "Automation stalled" to Admins: a single persistent alert per case and stage |
An operational example: a three-step policy
An escalation policy can have three steps. At time zero an in-app notification goes to the assignee. After four hours, if nobody has acted, an email goes to the manager. After one day, a webhook alerts the operations channel. Each step is therefore more visible than the last, and the case does not stay stuck without someone noticing. If an alert falls outside the time window, it is not sent at night: it waits and goes out at 08:00. When a colleague takes charge of the alert, in the example Marco after twelve minutes, the status records it and later steps are no longer needed. The diagram beside it is illustrative, with times and names as examples, and not an official screenshot. Notifications travel on the provided channels: in-app, email and webhook.
How to verify that alerts arrive
An escalation is reliable if you can verify what happened at each step. Check in the case history when each alert went out, to whom and on which channel, and whether it was postponed because of the time window. Then verify that the acknowledgment is recorded with who did it and after how long: acknowledgment time is a good indicator of how responsive the organization is. For external channels such as the webhook, look at the delivery status, which honestly declares whether it succeeded, failed or was unverified. From a governance angle this avoids the classic scenario where an alert was assumed sent and nobody ever received it. If an alert stays unacknowledged until the last step, the policy has still left proof that the organization was informed and when.
Related features
- Timeouts, SLA and exception routesReadable durations, a destination on expiry, and exception stages reachable only by the system.
- "Stalled automation" alertA single persistent alert to Admins when a stage has no valid exits or an AI fails.
- WIP limits and capacity queuesWork-in-progress limits per flow and per stage, with four possible reactions.
- Verifiable outbound webhooksWhen an event happens, FlowSharp notifies connected systems, with a per-attempt history.
- Dashboard and real timeKPIs, distribution by stage, times per stage and at-risk cases, updated in real time.
Use cases
Frequently asked questions
What is the difference between timeout and SLA?
A timeout acts on a single stage ("when it expires go to…"); an SLA measures the flow and can simply alert or move the case to escalation.
Can I avoid notifications at night?
Yes: with time windows, emails and webhooks are deferred to the opening of the window.
Can alerts start another process?
Yes: the "event" step can start an escalation-handling flow.
Who sees acknowledgement times?
Admins.