👤 For all users
🔐 Available on all plans
🎯 For those who want the process to react on its own when a deadline approaches or is missed, without depending on someone monitoring the queue
Stalled cards are the clearest sign of a process at risk. The request is in the pipe, the deadline is visible, but no one acted. When this repeats, the process loses credibility and the team starts managing emergencies instead of working with predictability.
Automatic escalation solves this without depending on someone actively monitoring the queue. The process reacts on its own when a deadline approaches or is missed, moving the card and notifying whoever needs to act before the problem turns into a crisis.
📖 What you'll understand here:
Three types of alert, three deadline logics
Before configuring any escalation automation, you need to understand which type of deadline you are monitoring. Pipefy offers three alerts with distinct logics, and each answers a different question.
- Due date alert: has the card passed the due date defined in the form? Use this for processes where each request has its own deadline, such as approvals with a specific deadline or deliveries with a date agreed with the client. The alert turns yellow when the date approaches and red when it passes.
- Late alert: has the card been in the same phase longer than allowed? Use this when the bottleneck is in a specific step of the process, regardless of the card's date. A support ticket that cannot stay more than 4 hours in "Analysis" uses a late alert on the phase, not a due date on the card.
- Expired alert: has the card been in the pipe longer than the entire process should take? Use this to control the end-to-end SLA, when the risk is not in a specific phase but in the total resolution time.
The choice of alert defines which event will trigger the escalation. Choosing wrong means monitoring the wrong symptom.
When each alert makes sense
| Situation | Correct alert |
|---|---|
| Each card has its own deadline (negotiated date, contractual deadline) | Due date |
| A specific step cannot take longer than X hours/days | Late (by phase) |
| The entire process cannot take longer than X days | Expired (by pipe) |
A common pitfall: configuring a due date alert when the real problem is time in phase. If the card was created with a 30-day deadline but has been stuck for 5 days in the same step, the due date will not signal anything for another 25 days. The late alert on the phase detects the problem much earlier.
The escalation logic: two chained automations
Regardless of the type of alert chosen, deadline escalation works with two automations that work together.
The first automation is time-based: it runs at regular intervals, checks all cards in the pipe and moves those that meet the deadline criterion to an escalation phase. It works like a periodic sweep of the queue.
The second automation is reactive: when a card enters the escalation phase, it fires the notification to whoever needs to act.
Separating the two automations is what makes the system robust. The sweep does not need to know who to notify. The notification does not need to know what the deadline criterion is. Each rule does one thing, and the two work independently.
A real use case
Process: IT ticket handling with a 5 business day SLA.
Problem: tickets without resolution reached the fifth day without the manager knowing. The team only noticed the SLA breach after the deadline passed, when the client was already dissatisfied and the ticket was already red in the pipe.
The configured alert: due date on the card, with the due date filled in the initial form.
The two automations:
- Automation 1: deadline sweep Event: recurring activity every hour Condition: field "due date" is exactly 1 day before today Action: move card to the "SLA Escalation" phase
- Automation 2: escalation notification Event: card enters the "SLA Escalation" phase Condition: none Action: send email template to the "responsible manager" field
With this configuration, the manager receives the warning 24 hours before the deadline for any ticket still open. The team starts resolving or escalating on day 4, instead of discovering the problem on day 6.
The escalation phase is not the card's final destination. After the notification, the card still needs to be moved to resolution, to a higher approval level or to reopening with a new deadline. Define beforehand who is responsible for that movement.
How to set the escalation lead time
The deadline configuration uses relative logic, not a fixed date. The criterion is not "move when the date is 06/15". It is "move when the due date is exactly X days ahead of today". This means the automation works for any card created in the future, without needing to be reconfigured.
The ideal lead time depends on the real time it takes to resolve the problem the escalation should address:
If the manager needs 1 day to step in and resolve, escalate with 1 day of lead time. If the escalation process involves more people and approvals, escalate with 3 to 5 days. Escalating on the due date itself is usually too late.
What to watch before activating
The sweep frequency defines the precision of the escalation. For SLAs in days, a daily sweep at a fixed time is usually enough and consumes fewer automation tasks. For SLAs in hours, sweeping every half hour makes a difference. Adjust the frequency to the level of precision the process requires.
Automation tasks are counted on every sweep. The recurring automation checks all cards in the pipe at each interval, even those that do not meet the deadline criterion. In pipes with a high volume of open cards, consumption can be significant. Monitor usage after activating.
Watch out for escalation loops. If a card is moved to the escalation phase and then returns to the previous phase with the deadline still active, the next sweep will move it again. Assess whether the condition needs an additional filter to prevent the same card from being escalated several times.
An SLA modified after a card is created does not affect existing cards. Changes to the late or expired alert configuration apply only to new cards and to the first time an existing card enters a phase with an SLA. Cards that are already late are not recalculated.
Before moving on, confirm:
☐ You have identified which type of alert monitors the correct deadline for your process (due date, late or expired)
☐ The date field used as the criterion is filled in the pipe cards
☐ The escalation phase exists in the pipe before creating the automations
☐ You have defined who is responsible for moving the card after the escalation
☐ Both automations are active and you have watched at least one card go through them
