Set up XLAs: profiles, timers and response deadlines

A traditional SLA is written for the worst case: a rigid clock whose job is to prove you didn’t miss a deadline. Thread’s XLA asks a different question — not “did we technically meet the contract” but “did the customer have a good experience getting help.” The same timers, business-hours logic and priority targets are underneath, pointed at a different goal: an early, honest read on how an experience is trending, so your team can act before a customer feels the miss.

​

Before you start: business hours

Each XLA profile runs its clock in one of two modes: If you plan to use During Business Hours Only on any profile, configure business hours first under Workspace Settings → Business Hours. They can be set workspace-wide, per team, or per client — the most specific wins. Holidays and custom closures are respected automatically and count as fully closed days, so a target stays realistic instead of quietly punishing your team over a holiday. A 24/7 profile never looks at business hours or holidays at all.

​

Create an XLA profile

Profiles live under Admin → XLAs. Each one bundles four things: who it applies to, which clock it runs on, how long each priority gets, and which statuses start, stop or pause the clock.

​

Timer controls

Below the targets, three status-mapping sections control the clock. The response timer also stops automatically the moment a client-facing reply is sent — you don’t need a status for that. The moment a human responds the experience has improved, so the clock reflects it immediately. Behaviours worth knowing:

• Enter a stop-response status and response time is done. Reopening restarts response fresh; it doesn’t touch resolution.
• While Triage Agent is actively working a conversation, both timers pause automatically — no configuration, universal. The customer is being helped.
• Reopen after Done and resolution resumes where it left off — the closed period doesn’t count against you. Response starts over, capped so it can never land later than the resolution deadline.
• A stop always wins over a pause if both would apply.

​

Profile order matters

The XLAs list ranks every profile top to bottom. When a ticket could match more than one, the first match wins — so put narrow rules (a VIP client, a specific board) above your general fallback. Drag rows to reorder. The list marks the highest- and lowest-priority ends, and a changed order flags itself so you don’t forget to save — reordering recalculates every affected ticket’s timers.

​

Saving and validation

Edits across the whole list — reorders, edits, deletes — are staged as a draft and applied together when you hit Save on the list page. Saving inside the profile editor only stages your changes back to that draft. Before staging, Thread checks that the profile has a name, its conditions don’t exactly duplicate another’s, the priority/source matrix has no blocking errors, and both Stop Resolution and Pause Resolution have at least one status.

​

Source-based overrides

A phone call and an email aren’t the same experience even when they’re triaged the same priority. Turn on source overrides and each priority gets its own card with:

• A default response/resolution target for all sources — the fallback.
• Add override to pick a ticket source synced from your PSA (email, phone, portal) and give it its own targets.

A source can only be overridden once per priority; once added it drops out of that priority’s picker but stays available for others. Removing an override falls that source back to the default. An exact (priority, source) override always wins over the priority’s any-source default, so the most specific timing applies.

​

How XLAs appear in Inbox

This is where the philosophy pays off — a continuously updating read on experience health rather than a pass/fail check at the deadline. Once enabled, technicians see it in two places on any ticket list in List display mode.

​

Countdown column

A live countdown to the next due date — response or resolution, whichever is active — refreshed roughly every 30 seconds and business-hours aware. “3h left” means three business hours.

​

Grouping by XLA

In the view’s Display menu, Grouping offers Date (default) or XLA, which buckets tickets by experience health: Breached · High risk · Moderate risk · Low risk · Resolved · No XLA Risk thresholds sit at the halfway and three-quarter marks of the target window — well before a breach — so a technician can see a ticket sliding toward High risk and step in while the experience can still be saved. Groups re-bucket live as thresholds are crossed, no refresh needed.

​

The ticket stepper

Every ticket with an active XLA shows a stepper reflecting elapsed and remaining time, its progression through the lifecycle, and a breached-when-done state if it resolved after the deadline had passed. Hovering names the XLA profile driving that ticket’s deadlines, so it’s clear which policy applied.

​

Alert on XLAs with a Flow

Flows can react to XLAs directly. When creating a Flow, choose the trigger “A Thread XLA is running out of time.” When a timer crosses the threshold, Thread posts a warning into that channel — “the response XLA for ticket #1234 is below 20% of its 4h target” — and posts the ticket card there just like any other Flow action. How it behaves:

• It checks roughly every 5 minutes, so a fire can land a few minutes either side of the exact threshold. Near-real-time, not precise.
• Each threshold fires once per ticket timer. Turning on a new XLA flow doesn’t flood you: it arms first, silently marking anything already past the line as handled, and only fires on tickets that cross afterwards.
• It respects the same business-hours math — on a business-hours profile, “20% remaining” is 20% of business time.
• Source overrides are respected, so the alert is calculated against whichever target actually applies to that ticket.

​

Known limitations