Watchlists are deadline monitors. They watch a datetime field on every open ticket, compare it to the current time, and bucket each ticket into a stage — approaching a future deadline, or elapsed past a past one. Agents see those stages in their dashboard so deadline pressure is visible. Workflows can fire on stage transitions so the system can act on deadline pressure without anyone watching it. This lesson covers building watchlists.

What a watchlist actually does

Problem: Of your 200 open tickets, some have SLA deadlines hitting in the next hour. Some haven't been touched in three days. Some are quietly past their resolution due date. Without a deadline monitor, that pressure is invisible — it surfaces only when a customer complains or when someone manually scans the queue.

Horizon's answer: Watchlists. A watchlist points at one datetime field on the ticket (SLA due date, last-touched timestamp, last-customer-response timestamp, anything else useful) and assigns each open ticket to a stage based on how close (or how far past) the watched moment is. Agents see those stages in their tray. Workflows can trigger off stage transitions to escalate, notify, or reassign automatically.

The system runs the scan periodically; you don't have to ask it to.

Where watchlists live

Open the admin panel and navigate to Components → Watchlists. You'll find:

A watchlist scan happens on a schedule. Between scans, the displayed stages may be slightly stale, but in practice the cadence is fast enough that agents see real-time-ish urgency.

Anatomy of a watchlist

A watchlist has:

• Name — what shows in the agent tray (e.g. "SLA Resolution Due").
• Watched field — the helpdesk datetime field being monitored. Must be a real datetime field that exists on tickets.
• Direction:
  • Approaching — counts down to a future moment. Use for deadlines (SLA due, scheduled appointment).
  • Elapsed — counts up from a past moment. Use for staleness (last touched, last customer response).
• Ticket filter (optional) — scope the watchlist to only certain tickets (e.g. "only tickets in status Open", "only tickets with priority High or above"). Without a filter, the watchlist applies to every open ticket.
• Stages — the buckets each matching ticket falls into.
• Is default — if true, this watchlist's tab is the one shown by default in the agent tray.
• Is active — toggle.

A stage has:

• Label — what agents see (e.g. "Due in 4h", "Overdue", "Untouched 3d+").
• Threshold (minutes) — the boundary that admits a ticket into this stage.
• Color — visual urgency cue. From a fixed color palette.

Stages are evaluated in order, so design them as a progression — "Due in 24h" → "Due in 4h" → "Due in 30m" → "Overdue". The colors should walk from calm to alarmed.

Creating a watchlist

1. Navigate to Components → Watchlists → Create.
2. Fill in:
   • Name.
   • Watched field — pick the datetime field to monitor.
   • Direction — Approaching for deadlines, Elapsed for staleness.
   • Ticket filter (optional) — scope as needed.
   • Is default — set to true if this should be the agent's default tray tab.
3. Add stages — one per urgency tier. For each, set the label, threshold (in minutes), and color.
4. Save.

Once saved, the watchlist begins scanning on the configured cadence. Agents see the new tab in their tray as soon as their next page load occurs.

Tip on stage thresholds: Always include a final "already past" (for Approaching) or "long-elapsed" (for Elapsed) stage at an extreme threshold (a very large negative number for Approaching, a very large positive number for Elapsed). That guarantees no ticket "falls off the end" — every ticket past your last meaningful threshold still appears, just in the most-urgent bucket.

Watchlist transitions as workflow triggers

A watchlist isn't just visibility. It can drive automation. When a ticket transitions between stages, an event fires that workflows can subscribe to.

Example patterns:

• Auto-escalate when a ticket enters the Overdue stage.
• Notify the assigned agent when a ticket hits "Due in 30m".
• Notify a manager when a ticket reaches "Untouched 3d+".
• Reassign automatically when a ticket sits in an Elapsed stage past a threshold.

The wiring is done via custom workflows that listen for the stage-transition event. Once configured, the workflow fires every time a ticket transitions into the target stage — no one has to be watching.

This is the place where watchlists become more than a dashboard widget. A team that uses watchlists only for visibility leaves most of the value on the table. Configure at least one transition workflow per watchlist (typically "notify on first elapsed stage") to start.

Where agents see watchlists

In the agent dashboard's Ticket Tray widget, each active watchlist appears as a tab with a count badge. The count is the number of the agent's tickets that fall into any of the watchlist's stages. Clicking the tab shows those tickets grouped by stage, color-coded.

If a watchlist has no agent-visible tickets at any stage, the tab doesn't appear for that agent.

The default watchlist (if you marked one) is the tab opened first.

Iterating on watchlists

Watchlists tend to start with one (SLA Due) and grow as the team identifies other deadline shapes worth tracking. Common second and third additions:

• Untouched — based on last activity timestamp.
• Awaiting Customer Response — based on last-customer-response timestamp.
• Approaching Booking — for tickets with scheduled customer meetings nearby.

Don't ship more than three or four watchlists — the agent tray gets noisy fast and counts become background noise. Each watchlist should answer a distinct question the team would otherwise ask manually.

Watchlist Scan Logs — debugging

Under Logs → Watchlists you'll find a record of each scan: which watchlist ran, when, how many tickets matched each stage, which transitions fired. When an expected workflow didn't fire, this is where you check to see whether the transition the workflow listens for actually happened.

When watchlists are set up correctly

• Active watchlists answer questions the team would otherwise ask manually.
• Stage thresholds and colors create a clear urgency progression.
• Each watchlist drives at least one transition workflow (notify, escalate, reassign).
• Agents check the Watchlists tab as a routine part of their day and report it actually catches things in time.
• Scan logs show clean scans with no errors.

Tip: A watchlist that only watches the helpdesk's SLA field is the easy starting point, but the higher-leverage watchlist is usually one that watches last activity — the "this ticket has gone quiet" signal. SLA breach is a known failure mode; staleness is an unknown one. Make staleness visible.