Most automations react to something happening. Support also needs automations that react to something not happening: a ticket solved four days ago that nobody objected to, a ticket twenty-four hours without a staff reply, a customer who was asked a question a week ago and never answered.
The Ticket Time Sweep trigger covers that. Once an hour DevStride walks every open (not Closed) ticket, works out how long it has been since a handful of moments, and runs your automation on the tickets that match.
Enabling Service Desk creates one Ticket Time Sweep automation, Auto-close solved tickets after 4 days: when a ticket has read as Solved for 96 calendar hours, it moves to your Closed status and the requester is emailed.
It is an ordinary automation on the Automate Workflows page. Edit the threshold, add conditions, change the action, pause it, or delete it; nothing recreates one you deliberately delete.
Create an automation (Setting Up Basic Automations) and pick Ticket Time Sweep under the Service Desk trigger category. Four elapsed-time conditions lead the condition list:
| Condition | Measures from |
|---|---|
| Hours Since Created | When the ticket was raised. |
| Hours Since Status Changed | When the ticket last entered its current status (creation time if it never moved). |
| Hours Since Staff Reply | Your team's last public reply. Internal notes don't count. A ticket never answered counts from creation, so first-response escalations always fire. |
| Hours Since Customer Reply | The customer's last reply, including one a colleague forwarded in on their behalf. |
Each takes is at least or is less than, a number of hours, and a mode:
Combine them with the ordinary ticket conditions (Customer Status, priority, team, assignee, work type, tags) to scope a rule. A sweep automation needs at least one condition and allows up to ten.
"No reply in 8 hours" against wall-clock time fires at 3am on Sunday for a ticket that arrived Saturday evening. Business hours counts only the hours your team is open, so eight business hours after a Friday-afternoon ticket is Monday morning.
Business hours come from a Schedule, the same ones SLA policies use. Per ticket, DevStride picks the calendar in this order:
If your organization has exactly one schedule, it is already your default and every team inherits it. A schedule still in use by a team, the default, or an SLA policy can't be deleted.
The Service Desk trigger category also offers event-driven triggers:
| Trigger | Fires when | Notes |
|---|---|---|
| Customer Replied | A customer posts a public reply by email or portal | The ticket is the subject; the comment and requester are available to templates. |
| Customer Marked Solved | A customer clicks Mark solved in the portal | Fires even if no Solved-mapped status exists to move the ticket to. |
| SLA At Risk / SLA Breached | A timer enters its last 20% / misses its target | See SLA. |
| Channel Message Suspended | An inbound email is held on the Held for review tab | No ticket exists yet, so only Send Notification and Call Webhook actions apply. |
| Item Request Submitted | A request form is submitted | Fires for every form, ticket or not. |
Send Customer Reply posts a public reply on the triggering ticket and emails it to the requester. It is offered on Customer Replied, SLA At Risk, SLA Breached, Customer Marked Solved, and Ticket Time Sweep, where a ticket exists to reply to. Use it for acknowledgements, SLA apologies, and closure notices; keep it short and avoid anything a human should say.
Service Level Agreements (SLA)
Promise how fast your team responds to and resolves tickets, have DevStride track the clock against your business hours, pause it while you wait on the customer, and get warned or reply automatically before a promise is missed.
Reports
Six built-in support reports (volume, first response, time to resolution, SLA attainment, agent activity, first-contact resolution) with date range, bucketing, grouping, an SLA-only toggle, and CSV export.