Tickets arrive messy. Priority is missing or wrong. Type is whatever the customer picked from a portal dropdown. Description is a one-liner that doesn't explain what's actually broken. Before any of that ticket can be assigned sensibly, someone has to clean it up and classify it. That's triage. This lesson covers what triage is in Horizon, how it's different from assignment, and the two ways a dispatcher runs it on a single ticket.

What triage is

Problem: A ticket lands. Its fields are unreliable. The customer marked it Critical because every customer marks every ticket Critical. Type is set to General because that's the portal's default. There's no queue assigned. If you skip straight to assignment, you're routing on garbage data — the wrong tier picks it up, the wrong agent gets it, the wrong SLA clock starts.

Horizon's answer: A triage policy is an admin-configured rule set (some deterministic logic, often paired with AI) that reads the ticket's title, description, customer context, and history, then produces a recommendation — "set priority to Medium, type to Network, queue to NOC."

You review the recommendation, then commit. The committed values get written to the helpdesk. Triage is a two-phase action: resolve (compute the recommendation, side-effect-free) and commit (apply the changes). You see the proposed changes before anything is written.

Triage is classification only. It sets fields on the ticket. It does not pick an assignee — that's a separate action covered in Your First Actions and Bulk Actions and Smart Assignment.

Triage vs. assignment — keep them straight

A clean triage motion: Run Triage → review the recommendation → commit → then assign. Triage feeds the assignment decision; running them in the wrong order means you're routing tickets before they've been classified.

Automatic triage vs. manual triage

Most accounts have triage running automatically via the Ticket Lifecycle. A status rule (typically on the New status) calls a triage policy whenever a ticket arrives. The dispatcher never lifts a finger — by the time the ticket shows up in the Ticket Board, it's already triaged.

Manual triage is for the cases where automatic didn't run, didn't get it right, or doesn't exist:

• A ticket bypassed the lifecycle — created through a path that doesn't trigger the status rule.
• The automatic triage picked a wrong field value and you want to re-run with a different policy.
• You're testing a new policy on a real ticket before turning it on for everyone.
• Your account is mid-cutover and triage hasn't been wired into the lifecycle yet.

If you find yourself running manual triage on every ticket, that's a sign the lifecycle isn't doing its job — flag it to your admin.

Method 1: Triage from the Ticket Board

1. Open the Ticket Board.
2. Find the ticket. Click the row.
3. The ticket modal opens. In the modal's actions, click Run Triage.
4. The triage form opens. Pick a Policy — your account's default is preselected.
5. Wait for the preview. Horizon analyzes the ticket and shows the proposed field changes.
6. Read the preview. If it's wrong, change the policy or cancel out.
7. If it's right, submit. The recommendation commits and the field changes get written to the helpdesk.

The triage modal closes. The Ticket Board row updates with the new field values.

You can now assign the ticket using Direct Assign, Smart Assign, or Add to Queue — covered in the assignment lessons.

Method 2: Triage from the Ticket Widget (inside the helpdesk)

If you live inside Autotask, ConnectWise Manage, or Zoho Desk most of the day, you don't need to leave to triage. The Horizon ticket widget that loads inside your helpdesk's ticket page exposes the same Run Triage action.

1. Open the ticket in your helpdesk.
2. Find the Horizon ticket widget on the page (this is the widget set up under Adding Horizon [Helpdesk] Widgets — if you don't see it, that step wasn't done).
3. Click Run Triage in the widget.
4. Pick a Policy — default preselected.
5. Wait for the preview. Same analysis as the Ticket Board version, same proposed changes.
6. Read it, submit.

Same backend. Same recommendation. The only difference is where you triggered it from. The committed values land in the same fields the same way.

When to use the widget instead of the Ticket Board: when you're already in the helpdesk's ticket page for some other reason — adding a note, looking at history, replying to the customer. Don't navigate away just to triage; do it where you are.

What you see after triage runs

• The ticket's fields update in the helpdesk (priority, type, queue, whatever the policy sets).
• A row appears in the Triage Logs with the recommendation, the committed values, and any policy diagnostics. (Admins read these; you don't usually need to.)
• If the triage changed a field that the lifecycle keys off (e.g. status, priority), downstream lifecycle actions fire — assignment, notifications, scheduled todos. That cascade is intentional.

Bulk triage exists too

The Ticket Board has a Bulk Run Triage action — pick a policy, apply it to many tickets at once. Useful when a batch arrives un-triaged (a migration, a backlog, an integration that bypassed the lifecycle).

Full coverage in Bulk Actions and Smart Assignment. Don't bulk-triage a list of tickets that have already been triaged correctly — re-running can overwrite manual overrides.

When triage is working correctly

• New tickets show up in your Ticket Board already classified — sane priority, sane type, in the right queue.
• The Triage Logs show clean recommendations that match what you would have picked manually.
• You rarely need to run manual triage. When you do, it's for an edge case, not for every ticket.
• The handoff from triage to assignment is automatic — you don't think about it.

If you're running manual triage on more than the occasional ticket, the policy or the lifecycle (or both) needs work. That's an admin-side fix.

Tip: Read the preview before you submit. The preview is the entire point of two-phase triage — Horizon shows you what it will change, and you get to bail if it looks wrong. Click-and-submit blind defeats the safeguard. If you find yourself rubber-stamping every recommendation, either the policy is excellent (good — trust it more) or you've stopped paying attention (bad — fix that).

Tip: When the recommendation is consistently wrong on a class of tickets, that's a policy config problem, not a triage problem. Capture two or three examples and bring them to your admin. "This policy puts every ticket from CustomerX into the wrong queue" is actionable feedback. "Triage is broken" is not.

Tip: The widget and the Ticket Board produce the same result. Pick whichever surface you're already in. The one mistake is bouncing between the helpdesk and the dispatch panel just to triage one ticket — that's three context switches you don't need.