The final lesson. Horizon does a lot automatically — triage, routing, escalation, watchlist reactions, helpdesk side effects. This lesson covers how much you actually touch (vs. what the system handles), how watchlists drive both visibility and automation, and what happens when you click an action.

Manual vs Automatic — How Much You Actually Touch

Problem: Horizon can do a lot of dispatch work for you — triaging tickets, routing them to agents, escalating stuck work, scheduling todos, reacting to deadline thresholds. Or it can defer all of those decisions to a human (you). Which mode your account is in changes your job description completely. If you don't know what's automatic and what's manual on your account, you'll either step on the system's toes or wait for the system to act on things it was never going to touch.

Horizon's answer: Almost every dispatcher-facing action in Horizon has both an automatic mode and a manual mode. Your admin decides — per action, per account — which mode is on. Day one of your dispatcher seat: find out.

The actions that have manual / automatic modes

Mixed mode is normal

Most accounts run a mix: some actions automatic, some manual, some manual-with-an-automatic-fallback. Common patterns:

• Auto-triage everything, dispatcher reviews edge cases. Triage runs on every new ticket; the dispatcher only intervenes when the recommendation is obviously wrong.
• Auto-dispatch normal-priority work, dispatcher handles VIP and complex. The system routes the easy stuff; the dispatcher takes the high-touch tickets.
• Auto-escalate by status timer, dispatcher intervenes early when needed. Tickets escalate automatically after sitting too long; the dispatcher can escalate sooner when they spot a problem.
• Manual scheduling for customer-facing work, auto-scheduling for internal todos. Onsites and calls are dispatcher-scheduled; floating internal work fits itself into the gaps.

How to find out what your account does

There's no single screen that shows you "here's everything that's automatic on your account." You learn it through:

1. Ask your admin directly. "Which actions are automated? Where do you expect me to step in?" This is the fastest path.
2. Watch the ticket history on a few sample tickets. Look at the actions taken — were they done by the system or by a person? Patterns emerge fast.
3. Sit with the outgoing dispatcher (or a senior peer) for a shift. Watch what they actually do vs. what they let happen.

What changes for you depending on the mix

• Heavy automation = your job is exception handling. Most of your day is reading what the system did, occasionally overriding when it's wrong, and watching for patterns that suggest a policy needs to change. Less doing, more reading.
• Heavy manual = your job is active routing. Most of your day is on the Ticket Board moving work to people. More doing, less reading.

Neither is right or wrong — it's a calibration choice your admin makes based on team size, ticket volume, and how much trust they have in the policies.

Tip: When something happens automatically that you would have done differently, don't just override it once and move on. Note it. Patterns in your overrides are the signal that policies need adjusting. Bring those patterns to your admin every couple of weeks. The system gets smarter when humans push back; it stays dumb when humans just paper over its mistakes silently.

Watchlists

Problem: The team has a hundred open tickets. Some are quietly ticking toward an SLA breach. Some haven't been touched in days. Some are fine. You can't tell at a glance which is which without scanning every row and doing the math.

Horizon's answer: Watchlists. A watchlist is a deadline monitor your admin sets up to bucket open tickets into urgency stages — color-coded by how close (or how far past) they are to a watched deadline. As a dispatcher, you see the team-wide view: every ticket across every agent, surfaced through any active watchlist.

What a watchlist actually does

Each watchlist watches a specific datetime field on the ticket — could be the SLA resolution due date, the last-updated timestamp, the last-customer-response timestamp, or anything else your admin picks. It then assigns each open ticket to a stage based on how many minutes remain or have elapsed:

• Approaching stages — counting down to a future moment. Example (watching SLA due date): "Due in 24h," "Due in 4h," "Due in 30m," getting more urgent as time runs out.
• Elapsed stages — counting up from a past moment. Example (watching last-touched timestamp): "Untouched 4h," "Untouched 1d," "Untouched 3d+," getting more urgent the longer the ticket sits.

Your admin defines which field is watched, what stages exist, the time thresholds, and the colors.

Watchlists are also a workflow trigger

Beyond visibility, watchlists can drive automation. Your admin can wire workflows to fire as a ticket moves between stages — meaning the system can act on deadline pressure without anyone watching it. Common patterns:

• Auto-escalate when a ticket enters the "Overdue" stage.
• Notify the assigned agent (email, in-app, or both) when a ticket hits "Due in 30m."
• Notify a manager (or you, the dispatcher) when a ticket reaches "Untouched 3d+."
• Reassign automatically when a ticket sits in an elapsed stage past a threshold.

You don't configure these — your admin does — but it's worth knowing they exist. If a ticket suddenly gets reassigned, escalated, or you get a notification about it, a watchlist trigger may be the reason.

Where you see watchlists as a dispatcher

The Dispatch Tray widget on your Dashboard has a Watchlists tab with a count badge. The count is the number of team tickets (across all agents) currently in any active watchlist's stages.

Internally the tab key is "deadlines" — but it's labeled Watchlists in the UI, matching the rest of the product.

Click the Watchlists tab to see those tickets, grouped by stage, color-coded by urgency.

If the Watchlists tab doesn't appear, the team has no tickets currently in any watchlist's tracked range. That's a good sign — nothing on a hot deadline.

Filter to a specific watchlist or stage

If your account has multiple watchlists (e.g. one for SLA response, one for SLA resolution), narrow the view:

• Pick a specific watchlist from the dropdown to see only tickets within that watchlist.
• Pick a specific stage to see only tickets in (for example) the "Overdue" bucket.

Dispatcher view vs. agent view of the same watchlist

You're looking for things the agent assigned to the ticket may not have noticed — because they're focused on their own work, while you're watching the whole team.

How to use the dispatcher Watchlists view

Dispatcher daily rhythm with watchlists:

1. Start of shift — open the Watchlists tab. If anything is in an "Overdue" or "Untouched 3d+"-style stage, deal with that first.
2. Mid-shift — glance occasionally. If something just entered a critical stage, decide whether to nudge the agent, reassign, or escalate.
3. End of shift — quick scan to make sure nothing rolled into a worse stage on your watch.

Common dispatcher actions when you see a ticket in a hot stage:

• Ping the assigned agent — "Hey, ticket #4521 is about to breach. What's the status?"
• Reassign if the current agent is stuck or unavailable — direct-assign to someone who can move it now, or smart-assign UP.
• Escalate if it's beyond the team's level — smart-assign UP.
• Update the customer if there's nothing else to do — better a "we're working on it" than a silent breach.

You don't create watchlists

Watchlists are configured by your admin in the admin panel. If you think a watchlist should exist for a deadline that isn't being tracked (e.g. an internal SLA your team committed to that's not in the system), tell your admin or open a support ticket.

Tip: Make the Watchlists tab the first thing you check every morning, before you even open the Ticket Board. SLA breaches usually happen because nobody noticed the timer — and the dispatcher is the closest person to that timer for the whole team. The watchlist is the timer, made visible. Use it before it bites

Running Triage

Problem: A ticket comes in with bad metadata — wrong priority, missing subtype, no assignee level. Without that metadata, dispatch can't route it correctly. Setting it manually on every ticket is slow; getting it wrong is worse. You want the system to apply a consistent set of rules to clean up incoming tickets.

Horizon's answer: Triage policies. Your admin defines rules ("if subject mentions 'down' set priority to High," "if customer is on tier-1 plan route to senior team," etc.) bundled into a triage policy. The policy can run automatically or you can run it manually on selected tickets.

How automatic vs. manual triage works on your account

Per the Manual vs Automatic section above, your admin decides whether triage runs automatically (on every new ticket / status change) or whether dispatchers run it on demand. Most accounts run a mix: auto-triage everything new, dispatchers re-run when needed (imported tickets, edge cases, after a manual change).

If your account auto-triages, you'll mostly read triage results and only run it on exceptions. If your account defers to dispatchers, running triage is part of your daily flow.

Run triage on a single ticket

1. Open the ticket — from the Ticket Board, the Dashboard, or the helpdesk widget.
2. Click Run Triage.
3. Pick a policy from the dropdown (defaults to your account's default policy).
4. The form runs the analysis and shows a preview of recommended changes — what fields will be set, to what values.
5. Either:
   • Apply — every recommendation in the preview is applied to the ticket.
   • Cancel — nothing changes; close the modal.

Run triage in bulk

1. On the Ticket Board, select multiple tickets.
2. Click Run Triage in the toolbar.
3. Pick a policy.
4. The system runs the policy across all selected tickets and shows results.
5. Apply or cancel — same all-or-nothing for the whole batch.

The policy runs individually per ticket — different tickets may end up with different recommendations based on their own context. But the apply / cancel decision applies to the whole batch.

The all-or-nothing limitation

This is the part dispatchers find frustrating: you can't cherry-pick. The preview shows you everything the policy wants to change. If you don't like one of the changes, your only option is to cancel and live with the original state — there's no "apply the priority change but skip the routing change" button.

What you can do:

• Cancel and edit manually. If the recommendation is mostly right but one field is wrong, cancel the triage, then edit the ticket directly to make the changes you wanted.
• Tell your admin. If you find yourself frequently cancelling triage because of one consistently-wrong recommendation, that's a policy bug. The fix is in the admin panel, not on your end.
• Run a different policy. If your account has multiple triage policies, one of them might match your intent better.

Reading the preview

The preview lists every field the policy wants to change, with the proposed value. Look at:

• Does the priority make sense? Wrong priority is the most common triage mistake.
• Does the routing target the right team? A misroute now costs everyone time later.
• Are any custom fields being overwritten? Some triage policies will overwrite values that an agent set manually. Check before applying.

If something's off, cancel. Triage is suggestion plus apply, not "the system has decided" — you're the gate.

When to run triage

• A batch of imported / migrated tickets needs metadata applied.
• A ticket was just created and your account doesn't auto-triage.
• A ticket's content changed significantly (e.g. customer added critical info) and you want fresh recommendations.
• You're cleaning up a queue of stale tickets that were triaged with an older policy.

When NOT to run triage

• The ticket has good metadata already and you'd be re-triaging just to be thorough — leave it alone.
• An agent has manually set fields and you don't want to overwrite them.
• You're running it because "why not" — every triage run can change things; only run with intent.

Common errors

• "No triage policy configured" — your admin hasn't created any. Talk to them.
• "Policy returned no recommendations" — the policy ran but didn't have anything to say about this ticket (no rules matched). The ticket is fine as-is according to the policy.

Tip: When you run triage and immediately cancel because the recommendations were wrong, write down what was wrong. Patterns over a couple of weeks become the data your admin needs to refine the policy. "Triage keeps recommending priority Medium for VIP customers — VIP should always be High" is actionable feedback. Silent cancels go nowhere.

Helpdesk Actions

Problem: When you assign a ticket, run triage, or an agent completes a todo, things often need to also happen in the helpdesk — set a status field, write a time entry, post a note, update a custom field, send a customer email. Doing those side effects manually after every dispatcher action is busywork. Forgetting them is worse.

Horizon's answer: Helpdesk Actions (internally called PostCommitActions). Admin-defined side effects that fire automatically after specific dispatcher / system events. You don't trigger them yourself — they ride on top of actions you (or the system) already take.

The trigger model

Helpdesk actions fire after one of these events:

• Ticket assignment — when a ticket gets a new assignee (direct assign, smart assign, dispatch, escalation).
• Triage execution — when a triage policy applies recommendations.
• Todo lifecycle events — when a todo is created, started, completed, cancelled, or deferred.

Every event is a potential trigger. Your admin maps events to actions: "when a todo is started, post a note in the helpdesk saying 'work began,'" "when a ticket is assigned to the Senior team, set status to 'Escalated' in the helpdesk," etc.

What helpdesk actions actually do

Whatever your admin configures. Common patterns:

• Update helpdesk fields — status, priority, custom fields, assignee role.
• Post internal notes or comments — auto-generated context for whoever opens the ticket next.
• Trigger external systems — webhooks, email notifications, integrations.
• Create related work — sub-tasks, follow-up tickets, calendar entries.

The exact list is per-account. There's no universal Horizon helpdesk action — they're rules your admin builds.

Why dispatchers need to know about them

You won't be configuring helpdesk actions, but you will see their effects. Three reasons to care:

1. Things happen "by themselves" that look like magic

You direct-assign a ticket and notice the helpdesk status changed automatically. You create a todo and a note appears on the ticket without you typing anything. Those aren't bugs — they're helpdesk actions firing.

2. Diagnosing why something happened

When an agent says "why did the ticket status change to Escalated when I assigned it?" — the answer is usually a helpdesk action your admin set up. Knowing the concept exists lets you give the right answer ("it's a configured side effect of assigning to Senior") instead of treating it as a mystery.

3. Spotting when an action didn't fire

If you direct-assign and the expected side effect doesn't happen, that's worth flagging. Either the rule isn't configured for that scenario (admin should fix), or it failed silently (worth a support ticket).

Manual mode? Sort of

Most actions in Horizon have a manual and an automatic mode. Helpdesk actions are different — they're inherently automatic. There's no "manually trigger this PostCommitAction" button. If a side effect isn't firing automatically and you need it to happen, you do it yourself in the helpdesk (set the field, post the note) and tell your admin to wire up the rule for next time.

The "PostCommit" name (for when you see it in logs)

You may see the term PostCommitActions in error messages, support tickets, or log output. That's the internal name. "Helpdesk Actions" is the user-facing name we use in this guide. Same thing.

Common patterns you'll see in practice

• Direct-assigning to a senior team auto-changes the ticket status to Escalated.
• Completing the "Initial diagnosis" todo posts a note on the ticket: "Initial diagnosis complete; awaiting customer response."
• Triage that sets priority to High auto-creates a follow-up scheduled todo for a manager check-in.
• Smart-assigning UP triggers a Slack notification to the senior team's channel.
• Cancelling a todo with a specific reason adds an internal note explaining the cancellation.

The point: a lot more is happening on every dispatcher action than the action itself. The helpdesk side often gets richer because of helpdesk actions, not because anyone manually edited it.

Your relationship with helpdesk actions

• Read the ticket history when you're trying to understand what happened. The helpdesk actions usually leave a trail.
• Don't fight side effects you don't expect. First check the configuration with your admin — usually the action is doing what it's supposed to and you didn't realize the rule existed.
• When you keep manually doing the same side effect after every dispatcher action, ask your admin to automate it. "I'm always changing status to 'Escalated' after smart-assigning UP — can we make that automatic?" That's a perfect helpdesk action candidate.

Tip: When something automatic surprises you, treat it as a learning moment about your account's configuration, not a bug. Ask your admin: "What helpdesk action fired here?" The answer teaches you what's wired up. Over time you build a mental map of "this dispatcher action triggers these side effects" — and then dispatching feels less like surprises and more like running a system you actually understand.