Introduce a configurable “Wait” step and a “Ticket Last Updated” time-based trigger within flows. This enhancement would allow administrators to delay flow execution until a defined period has passed or until a ticket has remained idle for a specified number of minutes. The goal is to prevent flow collisions and unintended automation conflicts during the initial lifecycle of a ticket.

Currently, flows can trigger immediately when a ticket enters a new status or meets defined conditions. In environments where multiple flows operate on similar triggers—such as when a new ticket is created or marked as “New”—these automations can collide. As a result, flows may execute before a triage agent has an opportunity to review and update the ticket, leading to unintended status changes, duplicate actions, or conflicting updates. This creates operational friction and undermines workflow predictability. There is no native way to ensure a ticket has remained idle or unchanged for a set period before additional automation runs.

Add two related capabilities to the flow builder:

A configurable “Wait” step that pauses execution for a specified duration (e.g., 5 minutes) before proceeding to subsequent actions.

A “Ticket Last Updated” condition or trigger that evaluates whether a ticket has not been updated for a defined number of minutes. This condition should be configurable (e.g., “Last updated more than X minutes ago”) and usable within flow entry criteria or conditional branches.

While both options would add flexibility, the “Ticket Last Updated” condition provides greater control by ensuring that the ticket has been idle and that no other automations or agents have modified it during the defined timeframe. This would allow flows to run only when the ticket state is stable.

This enhancement would reduce automation conflicts, improve workflow reliability, and give teams more precise control over timing-dependent processes. It would allow triage agents to intervene before automated rules execute, decreasing unintended changes and rework. By ensuring a ticket is idle before triggering downstream actions, administrators can design more predictable, scalable automation systems.

Common scenarios include delaying auto-assignment or escalation flows on newly created tickets, allowing triage agents time to categorize or reprioritize incoming requests, and preventing overlapping flows that respond to the same initial status change. Teams managing high ticket volumes or complex automation environments would particularly benefit from greater temporal control within their flows.