Lifecycles are how everything you've configured so far gets wired together. Triage classifies, assignment picks an owner, scheduled todos land on the calendar, helpdesk actions write back — but something has to decide when each of those happens for a given ticket. That something is the ticket lifecycle. Form lifecycles do the same job for custom form submissions. This is the centerpiece of admin work.

Why lifecycles exist

Problem: A ticket arrives. You want triage to run. Then you want it routed and assigned. When the agent moves it to In Progress, you want a time entry started. When it closes, you want a follow-up todo created and a status pushed back to the helpdesk. Without a single place that orchestrates all of that, you end up wiring each piece independently — and the moment one trigger changes, three other things break.

Horizon's answer: Lifecycles. A lifecycle is a single, declarative description of what should happen as a ticket (or form submission) moves through its states. Define it once. Horizon translates it into the underlying workflow runs that fire at each step. You think and talk in lifecycle terms; the workflow engine runs the actual machinery in the background.

There are two kinds:

Both are configured at the top level of the admin nav (Ticket Lifecycle and Form Lifecycle are pinned).

Ticket Lifecycle — status rules

The ticket lifecycle is a list of status rules. Each rule says: "when a ticket enters status X (optionally matching filter Y), do these actions."

A status rule has:

• Status — which helpdesk picklist value (status) triggers the rule.
• Filter — optional ticket criteria. Without a filter, the rule is the catch-all for that status. With a filter, it only fires for matching tickets.
• Action — what to do. Options include running Triage, running Route + Assign, or both.
• Triage Policy — which triage policy to run (if action includes triage).
• Assign Policy — which TicketAssignPolicy to invoke (if action includes routing/assignment).
• Position — order matters when multiple rules could apply at the same status; lower position evaluates first.
• Workflow Enabled flag — whether the underlying workflow actually fires (a soft toggle without deleting the rule).

A typical baseline setup for a service desk looks like:

You can layer in narrower rules for special cases — "when status is New AND type is Alert, route to Alert Auto-Assign policy", "when status is Resolved AND priority is Critical, send a notification to the manager". The position field decides ordering when multiple rules would match.

Setting up your first ticket lifecycle rule

1. Navigate to Ticket Lifecycle.
2. Click Create.
3. Pick the Status — usually the helpdesk's New (or equivalent first status).
4. Leave Filter empty for the catch-all.
5. Pick the Action. For first-touch, choose the option that runs both triage and routing/assignment.
6. Pick the Triage Policy you set up earlier.
7. Pick the Assign Policy you set up earlier (your helpdesk auto-assign policy).
8. Set position — 1 for the first rule.
9. Save.

That single rule replaces a stack of manual configuration: when a new ticket arrives, triage runs, and once triage commits, routing picks the right assign policy and the assign policy picks the user. All in one orchestrated flow.

Test by creating a real ticket in the helpdesk. Watch the Triage Logs and Assignment Decision Log for the ticket's lifecycle in action.

Form Lifecycle — submission rules

When an agent submits a custom form on a ticket (covered in the next lesson), something needs to happen. A Request Manager Approval form should send a notification to the manager. A Vendor Escalation form should create a sub-ticket and notify the vendor contact. Without a form lifecycle, the form just stores data and nothing else.

Form lifecycle rules are simpler than ticket lifecycle rules — they're scoped to a single form, and they fire on submission:

• Form — which custom form this rule is for.
• Active flag.
• Actions — what runs when the form is submitted.

Each form gets at most one lifecycle rule. When the form is submitted, the rule's actions fire in order.

Setting up a form lifecycle rule

1. Make sure the custom form exists (next lesson covers form creation).
2. Navigate to Form Lifecycle → Create.
3. Pick the Form.
4. Save.
5. On the edit page, configure the Actions — notifications to send, helpdesk actions to run, sub-tickets to create, etc.

The form lifecycle rule is the bridge between "the agent filled out the form" and "these specific things now happen as a result." Without it, forms are just structured data with no consequences.

Lifecycles and workflows — the relationship

You'll see both terms in the system. Here's the difference:

• A lifecycle is the user-facing concept: "when this happens, do that". You think and configure in lifecycle terms.
• A workflow is the underlying execution engine. Each lifecycle rule generates one or more building blocks — internal workflow resources that actually run when triggered.

The Workflows page is mostly read-only for admins — it's where you go to inspect runs, debug failures, and see what the lifecycle compiled into. You don't usually edit workflows directly; you edit the lifecycle rules and let Horizon regenerate the underlying workflows.

The exception: custom workflows outside any lifecycle (e.g. a webhook-triggered automation, a scheduled cron-style task). Those live directly in the Workflows page and are configured there.

Testing and debugging lifecycles

Two pages matter:

• Workflows → Logs (per workflow): shows every run of a generated workflow with timing, inputs, and outputs.
• Workflows → Pre-Filter Logs: shows triggers that almost fired but were filtered out — useful when "the lifecycle didn't run on this ticket and I don't know why."

Workflow runs also have a DAG visualization widget showing the steps as a Mermaid graph. Useful for visualizing what a lifecycle rule actually does end-to-end.

When a ticket doesn't behave as expected:

1. Find the lifecycle rule that should have fired.
2. Confirm the rule is active and is_workflow_enabled.
3. Check the workflow logs for the underlying generated workflow.
4. If nothing fired, check the pre-filter logs — the trigger condition probably didn't match.
5. If the workflow ran but did the wrong thing, the rule's action configuration is wrong.

When lifecycles are set up correctly

• New tickets are auto-triaged and auto-assigned without manual intervention.
• Status transitions trigger the right helpdesk actions consistently.
• Form submissions consistently fire their attached actions.
• Workflow logs show clean, expected runs with no quiet failures.
• Admins describe behavior in "when X happens, Y runs" terms instead of "workflow N step 3" terms.

Tip: Build the ticket lifecycle status by status, not all at once. Start with the New status and a single catch-all rule that runs triage + assign. Get that solid. Then add the Resolved and Closed rules for cleanup. Add narrower rules with filters only when you've identified a specific case the catch-all gets wrong. Lifecycles get unmanageable fast if you create twenty rules upfront — most of them won't match anything you actually see.