Skip to main content
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 target row in an XLA profile (every priority, and every source override) has its own Coverage setting, so one profile can mix both: XLA profiles created before coverage could be set per priority were migrated automatically and keep working as before. If you plan to use Business Hours on any row, configure business hours first under Workspace Settings → Business Hours. They can be set workspace-wide, per team, or per client, the most specific wins.
If a company has no business hours configured and you save a profile with any Business Hours row, Thread blocks the save with an error rather than letting the profile misbehave silently. The error links to Set up Messenger Hours in a new tab, so your unsaved draft stays intact. Add business hours there, or switch those rows to 24/7, then save again.
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 row never looks at business hours or holidays at all.
Business Hours configuration in Thread Workspace Settings

Create an XLA profile

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

Click Create XLA

XLA profile editor in Thread Admin
2

Name it for the experience, not the contract

Prefer something like VIP — fast lane over a contract tier. The name is internal.
3

Choose when the XLA applies

Add conditions — agreement, agreement type, board, company, company type, contact, contact type, or location. A ticket must match all of them. Leave it empty and the profile matches every ticket.
Which conditions you’re offered depends on your PSA. HaloPSA hides contact type and location; Autotask hides agreement and contact type, because those fields don’t sync cleanly.
Thread blocks saving a profile whose conditions exactly duplicate another profile’s, even if their coverage differs, since a ticket can only ever match one XLA.
4

Set response and resolution targets and coverage per priority

One row per priority level, in minutes, hours or days. Think of these less as contractual deadlines and more as how long before this starts feeling slow to the customer.Resolution time must always be longer than response time on the same row.Use each row’s Coverage select to choose Business Hours or 24/7 for that priority. For example, run Critical on 24/7 and everything else on Business Hours. Hover the info icon next to Coverage for a reminder that 24/7 ignores business hours and holidays, while the timer controls below still stop and pause the clock.
Per-priority response and resolution target cards in an XLA profile

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.
Stop and pause timer status mapping sections in an XLA profile
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.
Paused timers re-anchor their target when they resume: the deadline and its risk milestones shift forward in lockstep by the pause length, so a timer that was paused doesn’t inherit a stale deadline once it starts counting again.

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. Under each profile name, the list summarizes its conditions and coverage, for example All tickets · 24/7. When a profile’s rows use different coverage, it shows Mixed coverage.
Profiles created before per-row coverage keep their behaviour. Every row inherited the profile’s previous clock setting, so nothing changes until you edit a row’s coverage.
XLA profile list showing ranked order with drag handles

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.
Saving recalculates due dates for every open ticket the profile affects. Above roughly 7,500 open tickets the save can’t complete synchronously and Thread asks you to narrow the profile’s board scope, a safety limit to keep saves fast, not a ceiling on coverage.

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 and coverage 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 and Coverage.
A new override row starts with its priority’s coverage. Change it independently, for example to run phone tickets 24/7 while email stays on Business Hours. 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.
Source-based override configuration for an XLA priority card

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.
Live XLA countdown column in an Inbox ticket list

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.
XLA grouping is only offered in List mode. Switching to chat/inbox mode falls back to date grouping automatically.
Display menu with XLA selected as the grouping option
Ticket list grouped by XLA health into Breached, High risk and Moderate risk buckets

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.”
1

Set a percent-remaining threshold

For the response timer, the resolution timer, or both independently — for example, fire when 20% of the response target is left.
Flow trigger configuration with percent-remaining thresholds for XLA timers
2

Pick the channel

Same as any other Flow, the Slack or Teams channel it posts into, or delete if not required.
3

Add action

Same as any other Flow.The Flow Add menu with PSA expanded, listing actions such as Priority, Status, Board, Assign, Reply, and Note
4

Click Save & Turn it on (Top Right Corner)

An XLA Flow with Set Priority and Agent Builder actions, and the Save button and on/off switch in the top right corner
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 and runs whatever action you have selected. 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 target row, “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