> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Halo SLA and Priorities

> For desks synced to HaloPSA — read Halo's SLA/priority interplay correctly: priority selects the response and fix targets within the client's SLA, and hold statuses pause the clock.

<Info>
  **Category:** PSA-Specific Workflows · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/psa-specific/halo-sla-and-priorities/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Service & Ops Manager](/start-here/roles/service-ops-manager), [Dispatcher](/start-here/roles/dispatcher)

**Outcome:** Faster Resolution & Response, Fewer Escalations & Less Noise

**When to use:** Setting or changing priority on a Halo-synced ticket, "when is this due?" / breach-risk assessment on a Halo desk, or explaining why two same-priority tickets have different deadlines.

**Run it:** on one ticket · across all at-risk tickets on a board · or as a Flow (triggered on ticket create or status change, to set/verify priority and SLA).

## Prompt

```
You are reading Halo's SLA/priority interplay. In HaloPSA the client's SLA and the ticket's
priority work as a pair: the SLA defines a target matrix, and the priority row selects which
response target and fix (resolution) target apply. Changing priority changes the deadlines — it
is an SLA action, not a cosmetic label.

1. Re-read the ticket at full detail — priority, status, and SLA state may have moved Halo-side
   since your last read.

2. Read the pair: which SLA applies (from the client/contract) and which priority is set (from
   the tenant's actual priority list). The deadlines are the intersection; never quote a target
   from priority alone without knowing the client's SLA, since Halo targets differ per SLA.

3. Distinguish the two clocks: response target (first agent response) and fix target
   (resolution). Report which is live and how much remains on each. A met response with a distant
   fix target is a different situation from an unmet response — say which.

4. Check pause state: hold-type statuses (waiting on customer/vendor/etc., per the desk's config)
   pause the SLA clock; verify the actual status against the desk's live status list rather than
   trusting a "waiting" phrase in a note. Only the status pauses the clock — a note does not.

5. When changing priority, treat it as a deadline change: state old → new priority and the
   resulting target shift, and justify from impact/urgency evidence in the thread (security and
   multi-user impact force high priority). Apply after confirmation; note the reason in a plain-
   text note.

6. Output: applicable SLA (as far as visible), priority, live clock(s) with remaining time or
   "target not visible from Thread", pause state, and breach-risk tier.

Always: re-read before any deadline claim or priority change; a Halo-side response may have
already met the target you are about to escalate over. Never lower a priority to avoid a breach —
that is deadline-gaming and shows in Halo's SLA reporting; escalate instead. Never quote deadlines
you cannot see: if SLA targets are not visible from Thread, report the priority and recommend
confirming the target matrix in Halo rather than inventing hours. Business-hours calendars vary
per SLA in Halo; do not convert targets to wall-clock times unless the coverage calendar is known.
Priority changes on client-facing tickets may trigger Halo notifications — call it out before
applying.
```


## Related topics

- [SLA Analytics](/skill-library/reporting-and-analytics/sla-analytics.md)
- [SLA Breach Risk Tiering](/skill-library/qa-and-closure/sla-breach-risk-tiering.md)
- [Using Variables in Magic AI and Magic Agents](/assistive-ai/variables.md)