Triage classifies. Booking links and scheduled todos handle the calendar layer. The next gap is who picks up the ticket. Without auto-assignment, dispatchers manually route every ticket to a specific person — fast at first, then slower as volume grows, then a bottleneck. This lesson covers the simplest, safest auto-assignment method: round-robin. We use it twice — once for alerts, once for helpdesk tickets.

Why round-robin first

Problem: A ticket lands. A team of agents could work it. Without a rule, someone has to pick. That someone usually picks based on memory ("who did the last one?"), bias ("Bob's faster"), or convenience ("whoever's free") — all of which are inconsistent and don't scale.

Horizon's answer: Round-robin assignment. The system rotates through team members in order, giving each one the next ticket. It's not the smartest method (it doesn't know who's actually free, who's faster on this ticket type, who's already overloaded), but it's fair, predictable, and requires no other configuration to work. That's why it's where every account starts.

We use it for two scenarios:

1. Alerts — monitoring-generated tickets that need to land on someone immediately so they get acknowledged.
2. Helpdesk tickets — customer-submitted tickets, after triage classifies them, that need an owner.

Same mechanism. Two policies, scoped differently.

How a ticket actually gets assigned

Before walking through the assignment pages, understand the chain. A ticket doesn't go straight from arrival to assignment — three pieces work together:

1. Ticket Lifecycle decides when assignment should run for a given ticket (e.g. "after triage commits", "when the ticket changes to status X"). Lifecycle is the orchestrator.
2. Ticket Routing matches ticket criteria to a specific TicketAssignPolicy. Routing answers "of all the policies we have, which one applies to this ticket?"
3. TicketAssignPolicy picks the actual user using its method (round-robin, least-tickets, next-available, etc.).

In most accounts, the lifecycle does the heavy lifting. You configure the ticket lifecycle (covered in a later lesson) to call assignment at the right step, and the lifecycle invokes routing → assignment in sequence. You rarely touch routing or assignment policies directly outside the lifecycle.

You will only configure routing rules and assignment policies hands-on in advanced situations — multi-tier escalation, region-specific routing, special policies for after-hours, etc. For the day-one round-robin setup we're doing in this lesson, you'll create the assignment policy here and then have the lifecycle reference it. The lifecycle lesson ties it all together.

Where assignment lives

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

Routing rules live nearby under Components → Ticket Routing — that's where ticket criteria match a policy, when you need to configure that explicitly.

Setup work is on Policies. The other pages are testing and audit.

The assignment policy model

An assignment policy says: "pick a user from this team using this method, escalating through these levels if needed." Three parts:

1. Levels — escalation tiers within the policy. Most basic policies have a single level. Multi-tier policies (Tier 1 → Tier 2 → Manager) use multiple levels with different teams and methods per level.
2. Method — how to pick a user within a level. Round-robin, least-tickets, next-available, etc.
3. Direction — when assignment runs, which way does it move through the levels. Three options:
   • UP — escalate to a higher level (e.g. "this Tier 1 ticket needs a Tier 2").
   • SIDEWAYS — reassign within the same level (e.g. "current owner is unavailable, pass to a peer").
   • DOWN — de-escalate to a lower level (rare; used when a higher-tier ticket can be safely handed back).

For round-robin policies, the only direction you'll usually configure is SIDEWAYS at a single level. UP and DOWN come into play with multi-tier escalation, which is a later layer.

Note what isn't on the policy: ticket-matching conditions. The policy doesn't decide "do I apply to this ticket?" — routing does. The policy just decides "given that I was picked, who gets it?"

Round-robin variants

Two flavors are available, both pick the next user in rotation order, but they differ in what pool they rotate through:

Most accounts start with Round-Robin (Team) because the team membership is the roster. Use Round-Robin (Assignment Level) when you've split a single team into multiple levels with overlapping but non-identical rosters.

Setting up the alerts policy

Alerts are usually low-context: a monitor fired, someone needs to acknowledge it. Round-robin is a perfect fit because the who matters less than the speed.

1. Navigate to Assignment → Policies → Create.
2. Name the policy (e.g. "Alert Auto-Assign").
3. Save.
4. On the edit page, click Manage Levels and add a single level:
   • Team — your alert-handling team (often your NOC or after-hours rotation).
   • Method — Round-Robin (Team).
   • Direction — SIDEWAYS (no escalation, just rotation among the team).
5. Save the level.

The policy now exists. To actually use it, the ticket lifecycle for alert tickets needs to invoke assignment with this policy at the right step (covered in the lifecycle lesson). If you have a custom routing rule that explicitly maps "tickets where type = Alert" to this policy, configure it under Components → Ticket Routing — but in most accounts, the lifecycle handles this and routing rules stay default.

Setting up the helpdesk policy

Helpdesk tickets are higher-context — triage has already classified them.

1. Navigate to Assignment → Policies → Create.
2. Name the policy (e.g. "Helpdesk Auto-Assign").
3. Save.
4. Click Manage Levels and add a single level:
   • Team — your service desk team.
   • Method — Round-Robin (Team).
   • Direction — SIDEWAYS.
5. Save the level.

Same as alerts: the lifecycle is what invokes this policy at the right step. If you have multiple service desk teams (e.g. by region, by skillset), you'll either configure routing rules upstream to pick the right policy, or model it as multi-level escalation within a single policy. Both are advanced patterns; for day-one setup, one team and one policy is enough.

Testing before going live — Simulation

Problem: You created the policy. You don't want to find out it does the wrong thing by watching real tickets get misassigned.

Horizon's answer: The Simulation page. Pick a real ticket (or a synthetic one), run it through the policy, and see who would have been picked, without committing the decision.

1. Navigate to Assignment → Simulation.
2. Pick the policy.
3. Pick a sample ticket (or build one by hand).
4. Run the simulation.
5. Confirm the recommended assignee makes sense.

If the simulation picks the wrong person, fix the policy before tickets start flowing through it.

Watching it work — Decision Log

After the policy is live, the Decision Log shows every assignment decision: which ticket, which policy, which method, which user, why. When an agent says "I shouldn't have gotten this ticket", the decision log tells you exactly why it happened.

The Errors page sits next to it: assignment attempts that failed (no eligible candidates, plugin error, locking conflict, etc.). If a ticket is sitting in triaged but unassigned state, the errors page tells you why.

What auto-assign respects automatically

Round-robin doesn't blindly rotate through everyone. It respects:

• Active status — inactive users are skipped.
• Team membership — only team members are eligible.
• Away periods — users marked away (via the In/Out feature) are skipped.
• Exclusive on-call coverage — users on an exclusive on-call schedule for a different level are excluded from this level's pool.

You don't configure these — they're built-in. But knowing they exist saves you a debugging session when you see "why didn't Bob get this ticket?" — check whether Bob is marked away, inactive, or scheduled on another exclusive duty.

When round-robin is set up correctly

• Every alert ticket gets an assignee within seconds of arrival.
• Every triaged helpdesk ticket gets an assignee within seconds of triage finishing.
• The Decision Log shows even rotation across team members over a week or two.
• The Errors page is empty (or trends toward empty).
• Agents stop asking "who should take this?" — the system has already picked.

Tip: Round-robin is intentionally dumb. It will happily assign a ticket to someone who's already buried, or to a Tier 1 person when a Tier 2 problem comes in. That's fine — it's a starting point. The next lesson layers in next-available assignment, which considers actual calendar load. Don't try to make round-robin smart by adding too many conditions or escalation levels. Get it working first, then upgrade the method.