With triage running, every new ticket arrives classified. The next layer is the calendar layer — turning classified tickets into committed time on someone's day. That's what scheduled todos do. This lesson covers the admin-side configuration that controls how scheduled todos behave once they exist: acceptance, helpdesk side effects, and auto-start / auto-close behavior.
Problem: Triage classifies a ticket, but it doesn't put the work on anyone's calendar. The customer was promised a remote session at 2pm Thursday. There's no calendar entry, no commitment, no reminder. Whoever takes the ticket has to manually create a calendar event, link it to the ticket, and remember to update both when something changes.
Horizon's answer: Scheduled todos. A scheduled todo is committed time on an agent's calendar, linked to a ticket. Once you've configured how scheduled todos should behave, they get created in three ways:
This lesson is about the configuration that governs all three sources.
Open the admin panel and navigate to Components → ToDos. You'll find:
| Page | What it does |
|---|---|
| Acceptance | controls whether new todos require explicit acceptance from the agent before they're committed |
| Post-Commit Actions | account-level helpdesk side effects that fire when todo operations succeed |
These two pages cover the account-wide defaults. The actual creation of scheduled todos happens elsewhere — booking links, workflow steps, agent action — but how they behave once created is controlled here.
Problem: A workflow auto-creates a scheduled todo on an agent's calendar. The agent didn't pick the time. They may not even know the todo exists until they look at their calendar tomorrow morning. Now they're committed to a 2pm slot they didn't agree to. That's how trust in the system breaks down.
Horizon's answer: Acceptance modes. You decide, per scenario, whether a new todo lands as accepted (committed immediately) or pending acceptance (the agent has to confirm).
The Acceptance page exposes five settings, one for each scenario:
| Setting | When it applies |
|---|---|
| Floating, self-created | floating todo created by the agent themselves |
| Floating, other-created | floating todo created by someone else (workflow, dispatcher, customer) |
| Scheduled, self-created | scheduled todo created by the agent themselves |
| Scheduled, other-created | scheduled todo created by someone else |
| Booking link | scheduled todo created by a customer self-booking |
Each setting has an acceptance mode. A common starting point:
You can tighten or loosen this later based on team behavior. If agents routinely ignore pending-acceptance todos, auto-accept is the wrong call. If agents complain about getting committed without warning, require acceptance.
Problem: A scheduled todo gets created, started, completed, or cancelled. Each of those events probably needs to be reflected in the helpdesk — a status change, a time entry, a note, a closed sub-ticket. Without configuration, none of that happens automatically and agents end up double-entering everything.
Horizon's answer: Post-commit actions on the ToDo cluster's Post-Commit Actions page. These are account-level presets that fire when ToDo operations succeed.
For each ToDo service type (create, update, complete, etc.), you pick a preset that defines the helpdesk side effects. Presets themselves are configured under Components → Helpdesk Actions (covered in the lifecycle lesson) — this page is just where you wire them up to ToDo operations.
A typical setup for an MSP:
These are defaults. Workflows can override on a per-case basis.
Problem: An agent finishes the work covered by a scheduled todo but forgets to mark the todo complete. Or the underlying ticket gets closed, but the todo lingers on the calendar as if work is still pending.
Horizon's answer: Two mechanisms run in the background:
These are configured at the account level via the underlying ticket filters (covered in a later lesson). The behavior keeps the calendar honest without requiring agents to manually close every todo.
To set expectations: most accounts don't manually create scheduled todos at scale. The scheduled todo creation paths are:
Floating todos (the other kind) are covered later when we set up next-available assignment.
Tip: The mistake most accounts make on day one is configuring everything to require acceptance and configuring no post-commit actions. Result: agents get a flood of pending todos, no helpdesk records change, and the scheduled-todo layer feels like extra busywork. Start with auto-accept for self-created and booking-link todos, require acceptance only for the dispatcher-creates-on-someone-else's-calendar case, and configure at least the complete post-commit action so closing a todo writes a time entry. That's the minimum to get the calendar layer paying its way.