👤 For process owners and teams handling requests
🔐 Phase SLAs available on all plans; automations subject to permissions and plan conditions
🎯 For anyone who wants to spot delays at each stage and agree on a response
A purchase request has an expected delivery date, yet it is still waiting for approval. The requester asks for an update, someone checks its status, and the team realizes it has never agreed on how long the decision should take. There is a final deadline, but expectations for the steps along the way still need to be defined.
By the end of this article, you will know how to choose the right deadline control in Pipefy, agree on a time limit for a phase, and establish a routine for responding when a request exceeds that limit.
📖 What you will learn:
Which deadline you need to track
In Pipefy, a pipe holds the process, phases represent its stages, and each card represents a request. Before setting an SLA, identify the commitment you need to make visible. SLA stands for service level agreement. Here, it defines the expected time for handling work.
Late: tracks how long a card stays in a phase.
Expired: tracks how long a card stays in the pipe before completion.
Overdue: tracks the card's due date.
For the purchase request, approval may need a time limit, while delivery has an agreed date. These answer separate questions: how long can the decision wait, and when must the request be fulfilled?
⚠ A phase SLA does not change the card's due date. The Community discussion SLA da fase, in Portuguese, explores this distinction.
If a request needs to be ready for an event on a particular date, the due date represents that commitment. Add a phase time limit when you also need to identify internal waits before delivery.
How to agree on time and ownership for each phase
A useful limit reflects the work done at that stage. In purchase approval, the commitment might be to review the request and record a decision. Supplier delivery belongs to a different part of the process.
Work with the people doing the task to agree on:
- What information must be available before the review can begin.
- What outcome allows the request to move forward.
- How long the work can reasonably wait.
- Who monitors the stage and who can help resolve outstanding items.
In a hypothetical example, the team agrees to review a purchase within 24 elapsed hours. This number illustrates the decision. Your limit depends on workload, capacity, and the commitment made to requesters.
When there is not enough history to guide you, start with an expectation the team considers fair and achievable. Observe the process and review the agreement as you learn where work waits. A limit that is far removed from daily practice provides little guidance on when to intervene.
💡 Include the time limit, owner, and a brief instruction in the phase description. For example: “Review within 24 elapsed hours. Owner: Purchasing team. Check the information and record the decision before moving forward.” The description communicates the agreement; card assignment must be established in the process.
How to apply the control and check the calendar
Once the team has agreed on the limit, identify the phase, duration, and time unit. The late alert is in the phase's advanced options and accepts minutes, hours, or days. This setting puts the agreed limit into practice.
🔗 Learn more: use the official guide to setting up alerts in a pipe to apply your decision.
Check which calendar matches the commitment. Excluding weekends is different from accounting for working hours and holidays. In the example, 24 elapsed hours includes time outside the team's working schedule. Confirm whether that is appropriate before applying the same value to your work.
When the deadline depends on working hours, holidays, and time zones, the Apply SLA rules action can calculate a date in a due date field. This is an automation application for the card's due date. It should not be treated as an automatic change to the phase's late alert.
🔗 Learn more: review Advanced SLA rules to evaluate that calendar.
How to respond when a phase exceeds its time limit
An alert helps identify a request that needs attention. The response comes from the team's agreement: check for missing information, contact the decision maker, or agree on a next step with the requester.
In purchase approval, a request might be waiting for an additional quote. Once the wait is identified, the team checks who can provide the document and agrees on the next action. Approval still follows the company's purchasing criteria.
💡 Agree on the response when you agree on the time limit. Decide who checks the alerts, who handles outstanding items, and when the team reviews requests still awaiting a decision.
If the process needs an automatic message, an alert can serve as an automation event. For phase delays, the time limit must be set before the rule. Sending an email or taking another action requires its own automation and validation of the result.
To explore how events, conditions, and actions work together, read Essential automations in Pipefy, in Portuguese. Plan the response before deciding whether it should be automated.
How to test and monitor deadlines in daily work
Start with one stage in a controlled environment. Use a sample request and a short limit to check the late alert. If you add an automation, validate the expected action and the people involved in the test separately.
⚠ Changing the SLA does not update existing alerts. The documentation limits new settings to new cards or a card's first entry into a phase with an SLA. Validate the change with a new scenario.
In daily work, a yellow clock identifies a phase delay. The indicator next to the phase name shows how many cards are late. Use that signal to decide what to investigate, then check the outstanding item on each request.
An initial routine might be to review these requests at the start of the day, agree on the next action, and revisit outstanding cases. Match the frequency to the process commitment. A queue that promises a response within hours needs monitoring that fits that interval.
When waits keep occurring at the same stage, investigate incoming work, available information, dependencies, and capacity. A delay tells you where to look. Understand its cause before changing the limit or reallocating work.
The number of active alerts describes the current operation. To understand how the process changes over time, connect this view to a regular review, such as the approach in Metrics every process should track, in Portuguese.
Before moving on, confirm that you understand:
☐ Phase delays, total time in the pipe, and a card's due date represent different commitments.
☐ Each time limit needs an agreed owner and operational response.
☐ A new scenario helps validate the limit and any automation before broader use.
Ready to track the process after your first test? → Metrics every process should track, in Portuguese
