Align time zones and calendars with process deadlines

A purchase request arrives late on Friday afternoon. The team promises a response within four hours, but the requester expects a decision that evening while the approver counts only working hours. There is an agreed deadline, but the team still needs to define which hours count toward it.

By the end of this article, you will know how to choose a calendar and reference time zone for a commitment, record exceptions, and check whether the due date matches the team's agreement.

What you will learn:

What commitment the deadline represents

Before choosing a calendar, identify what needs to happen by the deadline. An agreed date for receiving materials from a supplier represents a delivery. Four hours to approve a purchase represents a response window. Both commitments can belong to the same process and need to remain distinct.

In Pipefy, a pipe holds the process, each phase represents a stage, and each card represents a request. The card's due date records a deadline; a phase's late alert tracks time spent at that stage. To decide which to monitor, read Phase SLAs in Pipefy to keep deadlines on track.

For a deadline calculated from an event, agree on three things: the starting event, the duration, and the calendar. In the purchasing example, the team might count four working hours from request creation. If a review requires complete documentation, discuss whether that starting point reflects the commitment the team can make.

Which hours count toward the deadline

Elapsed time includes periods when the team is not working. Working time counts the periods defined in the agreement. To choose between them, consider whether service continues outside working hours and what has been communicated to requesters.

Consider a hypothetical calendar running Monday through Friday, from 9 AM to 6 PM, without breaks. A request arrives on Friday at 4 PM with a deadline of four working hours, using Brasília time. The manually calculated expectations would be:

• No holidays: two hours on Friday and two on Monday, giving an expected deadline of Monday at 11 AM.
• Monday defined as a holiday: the remaining two hours move to Tuesday, giving an expected deadline of 11 AM.
• A commitment of four elapsed hours: the deadline would be Friday at 8 PM.

These results illustrate the calculation under the example's assumptions. Use the same reasoning to calculate an expectation and compare it with a test card.

In Pipefy, the Apply SLA rules action can use working hours, entered holidays, and a time zone to calculate a Due Date field. See Advanced SLA rules to apply your chosen calendar.

Which time zone defines the commitment

Choose a time zone based on the operation responsible for the deadline, and include that reference alongside the time. If Purchasing works in Brasília time, that can define the commitment's calendar even when the requester works elsewhere. The choice should reflect the agreement between the parties.

The preferences of the person viewing the information also matter. The documentation links the Datetime field's time zone to profile settings. In an advanced SLA rule, the initial time zone comes from the user's preferences and can be changed. Check the time zone selected for the calculation explicitly, rather than assuming a personal preference represents the process.

In a hypothetical example, a delivery on November 20, 2026 at 5 PM in a location using UTC minus three corresponds to 9 PM in a location using UTC plus one on that date. This is the same instant expressed using different references. UTC provides a common reference for comparing times across locations.

How to check the calendar before using it

Choose a fictional request and write down the expected result before running the test. Record the starting event, duration, working days and hours, holidays, and time zone. This gives you a basis for checking whether the rule represents the agreed commitment.

Include situations that cross calendar boundaries:

• Arrival during working hours, to check the basic calculation.
• Arrival near closing time and outside working hours, to check the transition to another working period.
• Arrival before a weekend or holiday, to check exceptions.
• Views by people in different time zones, to check how the deadline is interpreted and communicated.

Compare the recorded due date with the manual expectation and document differences before extending use. If another action depends on that date, such as notifying the team, test the action and its recipient too. Checking the calculation and checking the communication are complementary tasks.

How to keep the agreement clear in daily work

Decide who reviews applicable holidays, who monitors changes to working hours, and who communicates a new agreement to requesters. One team may work normally on a day when the department responsible for the review is closed. The commitment's calendar needs to account for that difference.

Record the rule in language another person can interpret. For this example: “Response within four working hours of request creation. Working hours are Monday through Friday, 9 AM to 6 PM, Brasília time, considering the holidays defined for Purchasing.” Adapt the wording to your actual starting event and calendar.

When an agreement belongs to a phase, also record the responsible role and a short instruction in the phase description. This communicates expectations; applying the rule and checking it in a test are still necessary.

Start with one deadline and a representative scenario. Once you have checked the due date, decide how much advance notice the team needs to act. That connects the calendar to a routine for reminders based on dates.

Before moving on, confirm that you understand:

☐ The starting event, duration, and calendar need to represent the same commitment.

☐ Elapsed time, working hours, and holidays lead to different calculations.

☐ The rule's time zone should match the process agreement.

☐ A test compares the observed due date with an expectation calculated beforehand.