> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Set up XLAs: profiles, timers and response deadlines
> Build XLA profiles in Thread: business hours, match conditions, per-priority response and resolution targets, timer controls, source overrides, the Inbox countdown and XLA grouping, and the Flow trigger.
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.
**XLA** is an *Experience Level Agreement*. Your PSA holds the **SLA** — the contractual promise you sold, measured after the fact for billing and renewals. Thread's XLA measures the same clocks against what the customer actually experienced: it stops on a real human reply rather than an auto-acknowledgement, pauses while Triage Agent is still working the conversation, and respects your closures. Keep the SLA in the PSA as the contract; run the desk on the XLA. Configurations were renamed from SLA in [Q3 2026](/changelog/q3-2026) — existing profiles and timers carried over unchanged.
## Before you start: business hours
Each XLA profile runs its clock in one of two modes:
| Mode | What it means |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------- |
| **During Business Hours Only** | The clock counts only during business hours — accrual pauses outside the window and resumes when it reopens |
| **24/7 — All Hours** | The clock runs continuously, real time, regardless of when it is |
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.
If a company has no business hours configured and you save a profile that depends on them,
Thread **blocks the save** with an error rather than letting the profile misbehave silently.
[Holidays and custom closures](/inbox/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.
Prefer something like **VIP — fast lane** over a contract tier. The name is internal.
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 company type, contact type and location; **Autotask** hides agreement and contact type, because those fields don't sync cleanly.
Thread blocks saving a profile whose conditions and business-hours setting exactly duplicate another profile's, since a ticket can only ever match one XLA.
**During Business Hours Only** or **24/7 — All Hours**.
One card 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 card.
## Timer controls
Below the targets, three status-mapping sections control the clock.
| Control | What it does |
| -------------------------- | ------------------------------------------------------------------------------------------------ |
| **Stop Response Timer** | Statuses that stop the response timer for good |
| **Stop Resolution Timer** | Statuses that stop the resolution timer — typically Done/Closed. **At least one required.** |
| **Pause Resolution Timer** | Statuses that pause and later resume it — e.g. *Waiting on Customer*. **At least one required.** |
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.
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.
## 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 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.
XLA grouping is only offered in **List** mode. Switching to chat/inbox mode falls back to date
grouping automatically.
### 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."**
Same as any other Flow — the Slack or Teams channel it posts into.
For the response timer, the resolution timer, or both independently — for example, fire when 20% of the response target is left.
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
| Limit | Detail |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Ticket volume on save** | A profile save whose recalculation would scan more than **7,500 open tickets** can't save synchronously — narrow the board scope instead |
| **XLA Flows per workspace** | **10**. An accident guard rather than a capacity limit, but you'll need to delete one before adding an eleventh |
| **Flow check interval** | \~5 minutes, not instant |
See **XLA** updates in the [changelog](/changelog/q3-2026).
## Related topics
- [XLAs & dispatch](/start-here/roles/service-ops-manager/sla-and-dispatch.md)
- [Assign and schedule](/start-here/roles/dispatcher/assign-and-schedule.md)
- [Set up the desk](/start-here/roles/service-ops-manager/set-up-the-desk.md)