> ## Documentation Index
> Fetch the complete documentation index at: https://docs.helmkit.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Preflight
> Operational readiness for every tour — action items, templates, and the triage view that surfaces everything that needs attention
## What is Preflight?
Preflight is everything in Helm that makes sure a tour is operationally ready before it happens. It's the layer that answers: are guides assigned, are tickets sorted, are the small recurring tasks done, and is anything currently in a state we need to fix?
Most agencies run this out of band today — color codes on Google Calendar, letter prefixes in event titles, a shared spreadsheet of "things to check," a team member who just remembers. Preflight replaces those ad-hoc systems with a first-class one, built directly on top of your runs and events.
## The pillars
Preflight is a group of tools that work together. Some are already live, others are on the way.
| Pillar | What it does | Status |
| ---------------------- | --------------------------------------------------------------------------------------------------------- | ----------- |
| **Action Items** | Per-event task lists — manual and auto-generated. The data layer that tracks what needs doing. | Live |
| **Templates** | Per-experience preflight checklists, auto-created on every new booking. | Live |
| **Triage** | A single screen that surfaces everything across your organization currently in an attention-worthy state. | Live |
| **Reminders** | Deadline reminders and change notifications tied to action items, with per-context preferences. | Live |
| **Status Indicator** | A configurable multi-segment color bar on calendar cards, so you can see readiness at a glance. | Coming soon |
| **Card Configuration** | Composable calendar card layouts — pick what shows on your cards and how. | Coming soon |
This documentation covers the pillars that are live. Status Indicator and Card Configuration will be documented once they ship.
## Three surfaces, three questions
Preflight is designed to complement — not replace — the other two places in Helm where you look for information. Each surface answers a different question, so reaching for the right one is half the battle.
| Surface | The question it answers | How it's ordered | How an item leaves |
| ------------ | ---------------------------------- | ---------------------------- | ----------------------------------------- |
| **Inbox** | What happened to me? | By recency of activity | By reading it |
| **Calendar** | What's on the schedule? | By time | It doesn't — the schedule is the schedule |
| **Triage** | What needs my attention right now? | By urgency (priority + time) | By the underlying thing being resolved |
Inbox is push. Triage is pull. Inbox interrupts you when something happens;
Triage is a screen you check to see what's currently off. Both are useful, and
most things show up in both — a failing integration pushes to Inbox once and
stays in Triage until it's healthy again.
## Notifications and signals
Inside Preflight, two concepts shape how you find out about things: **notifications** and **signals**.
**Notifications** are events — something happened, you need to know. They arrive in your Inbox and (if you've enabled email) your email. Each notification fires once. Marking it read doesn't change anything about the thing it describes.
**Signals** are states — something is currently in a condition that warrants attention. They appear in Triage, and they clear themselves when the condition goes away. You don't mark a signal read; you resolve the thing it points to.
Many situations generate both. A WooCommerce sync failing will:
* Fire a notification to your Inbox so you know *now*
* Appear as a signal in Triage so it stays visible to everyone on the team *until* the integration is healthy again
Reading the notification doesn't clear the Triage entry. Clearing the Triage entry (by fixing the sync) doesn't mark the notification read. They describe the same situation but track it independently — you pick the surface that matches how you want to deal with it.
## Where to go next
Create and assign tasks on events, build reusable templates, and configure
who gets notified about what.
See everything across your organization that currently needs attention, filtered by
signal type, time horizon, or assignee.
## For administrators
A few things only organization admins can set up:
* **Action item templates** — under **Settings → Organization → Experiences**. See [Templates](/features/preflight/action-items/templates).
* **Which signals appear in Triage** — under **Settings → Organization → Triage**. See [the signal toggles](/features/preflight/triage/filters-and-views#turning-signals-on-or-off).
* **Requires tickets on a rate** — a checkbox inside each rate that tells Triage to watch for missing tickets on bookings of that rate. See [Configuring Requires tickets](/features/preflight/triage/filters-and-views#configuring-requires-tickets).
Every other Preflight setting — notification preferences, saved views, snoozes, follows — is per-user and lives in each team member's own profile settings.
## Terminology
A quick reference for terms used throughout this section:
* **Action item** — a single task attached to an event (or to the person who created it, for personal items).
* **Template** — a predefined action item attached to an experience or rate. When a new booking of that experience is created, a fresh copy of each template item is auto-created on the event.
* **Subscriber** — someone who gets notified about changes to an action item. Assignees are always subscribers; anyone else can follow an item (or a whole run) to become one.
* **Source** — the reason you became a subscriber (you created the item, you were assigned, you followed it). Sources determine your default notification profile.
* **Signal** — a named condition that Triage watches for. Examples include "action item overdue," "run with no guide assigned," "run missing tickets," and "integration sync failing." Signals check your live data every time you open Triage, so entries are always up to date with what's happening right now.
* **Entry** — one row in Triage: a specific thing currently matching a specific signal (e.g., "the Morning Walking Tour on Friday is missing tickets").
* **Snooze** — hide a Triage entry for yourself until a chosen time. Personal, doesn't affect anyone else.
* **View** — a saved combination of filters, sort, and horizon in Triage. Personal — you don't share views with your team.
* **Horizon** — the time window Triage is looking at (default: next 14 days). Signals without a time anchor, like sync failures, are always shown regardless.