A checklist in UAS Dashboard is a form your agency designs once and pilots fill out against a flight. It closes the flight out consistently, it decides what the public transparency portal says about that flight, and — the part most programs underuse — it builds a dataset you can chart. Building templates requires a Global Admin account; completing checklists is open to anyone with access to the flight's unit.
Before you start. Checklists are a licensed feature — included from the Starter plan up on the shared product, and governed by the instance's feature flags on an agency's own instance. If you do not see the Flight Checklists card in Admin, the feature is off for you.
How checklist templates work
A template is a named, ordered list of fields. Every template belongs to one of three phases, and the phase decides when it is filled in:
- Post-flight — completed against a flight after it lands. This is the phase the rest of the article refers to.
- Pre-flight — completed against a flight before takeoff. Optional; the card appears only when your agency has a pre-flight template.
- Pre-shift — completed once when a shift starts, not against a flight. It also stores a snapshot of the weather and nearby airspace the crew briefed on.
An agency with nothing configured gets a standard Post-Flight Checklist and Pre-Shift Log seeded automatically, so you start by editing rather than from a blank page. A flight holds one pre-flight and one post-flight response; a second post-flight submission is rejected, and you edit the existing one.
Building a template
Go to Admin → Operations → Flight Checklists → Manage checklists. The page groups templates by phase, with a New template button for each.
- Click the New template button for the phase you want, then give it a name (required) and an optional description.
- Add fields with Add field. Each takes a label, a type, optional helper text shown under the input, and a Required checkbox.
- For a
selectfield, add the choices in the Options list. A dropdown with no options will not save. - Drag fields by the grip handle to reorder them. This order is the order pilots see.
- Click Save template.
Fields with a blank label are dropped on save. To retire a template, click Deactivate — it stops being offered on new checklists, and completed ones keep their answers.
Editing a template does not rewrite history. Each completed checklist stores a snapshot of the fields as they were at completion, so a later edit to that response shows the fields the responder actually saw, not the current template.
Item types and what each is for
Six item types are available. The type matters more than it looks, because it decides whether the answer is chartable — see the last section.
| Type | Renders as | Good for | Chartable |
|---|---|---|---|
checkbox | A checkbox | Routine "did this happen" confirmations | Yes — Yes/No breakdown |
toggle | An on/off switch | Yes/no decisions the pilot should notice | Yes — Yes/No breakdown |
select | A dropdown of your options | Categories you want counted: outcome, mission type, disposition | Yes — answer breakdown |
number | A numeric input | Anything worth a monthly average: crew size, subjects located, minutes on scene | Yes — monthly average |
text | A single-line input | Case numbers, short labels, addresses | No |
textarea | A multi-line box | Narratives, notes, exception write-ups | No |
checkbox and toggle capture the same true/false value; the difference is presentation.
Completing a post-flight checklist
Open the flight from Flights and find the Post-Flight Checklist card. Until it is completed it sits at the top of the flight page with a Pending badge; afterwards it moves to the bottom and shows Completed.
- If your agency has more than one post-flight template, pick one from the dropdown at the top of the card.
- On DFR-enabled instances, answer the built-in Type of flight question — Field Deployment or DFR. It is required, is not part of any template, and drives the field-versus-DFR split in reporting.
- Fill the fields. Required ones are marked with a red asterisk; the submission is rejected listing any still empty.
- Click Submit checklist.
Submitting does more than store answers. The person who filled it joins the flight's participant list under a checklist role. A case or incident number answer becomes the flight's title (unless the title was set by hand) and is stored as the record's incident ID. And if the flight arrived from an integration with no pilot, or attributed to the catch-all import pilot, completing the checklist claims it and makes the filler the Remote PIC.
To change an answer later, open the card and click Edit — available to the person who completed the checklist and to Supervisors and above.
One checklist for a whole mission
When one response should cover a group of flights, switch the Flights page to the Missions view. Each mission row's Checklist column shows a Complete badge or a Fill checklist button with a count of the flights still uncovered. Filling it once applies that response to every flight in the mission without its own, up to 50 per submission. Those flights show the checklist read-only, badged as a mission checklist; edit it from the flight it was filed on.
Overdue tracking and completion enforcement
A post-flight checklist is overdue when the flight took off more than the agency's completion window ago and still has none completed. The window defaults to 24 hours and is set in Admin → Operations → Flight Checklists → Dashboard settings, where you can also turn the dashboard card off. Only the last 90 days count, so an old import does not permanently light up the dashboard.
The home dashboard's Checklists Overdue stat card links to the overdue list. Both are scoped by role:
| Role | Sees overdue checklists for |
|---|---|
| System Admin, Global Admin | Every flight in the agency |
| Unit Admin, Supervisor | Flights in their unit |
| Pilot | Their own flights |
The overdue list is a searchable, sortable table of flight date, pilot, unit, and flight, with a Complete checklist button on each row.
Shift logs enforce completion. A shift log cannot be marked complete while any flight in it is missing its post-flight checklist. The save is rejected and the message names the flights that still need one. This is what actually keeps completion rates high — the overdue card only reports.
What the checklist publishes to the public portal
On instances running the public transparency portal, the checklist and the portal are one mechanism. While the portal is enabled, two questions are added to every active post-flight template and locked there with a Portal badge:
- Public page summary — a required short text answer such as "Theft" or "Fire."
- Remove this flight from the public page? — a toggle.
You can reword the label and helper text and drag them elsewhere in the list, but you cannot delete them or change their type while the portal is on; the server enforces this on every save. Disable the portal and both are stripped from active post-flight templates automatically.
That toggle is the only control over a flight's portal visibility: the portal is opt-out, and the checklist is where you opt a flight out. Switch it on and the public summary stops being required, since a hidden flight needs no public text.
The narrative comes from the answers rather than a separately maintained field: the portal uses the first non-empty text answer whose field key or label contains "summary," "narrative," "desc," or "note." A Short narrative field publishes if you write one, with the public summary as the fallback, and the case or incident number is published as the flight's incident ID. See the public transparency portal article for portal configuration, and the AB 481 guide for the disclosure obligations behind it.
Collect it, chart it
This is the payoff, and it is worth designing your templates around. Every number, select, toggle, and checkbox item across your templates is automatically offered as a chart — no configuration, no mapping step, nothing to register. Add a field today and it appears in the chart picker once answers come in. The three shapes:
- `number` → a monthly average line, titled "Your label — monthly average."
- `select` → a breakdown pie, one slice per answer, ordered by count.
- `toggle` and `checkbox` → a Yes/No breakdown pie.
Free-text fields — text and textarea — are not aggregated; there is nothing to count in a paragraph. If you want an answer on a chart, ask it as a dropdown or a number. A "What was the outcome?" textarea gives you a searchable record; the same question as a select with six options gives you a chart and a record.
To put one on a page, go to Admin → Organization and open the Report Charts card (Program Charts on the Reports page) or the DFR Charts card (the DFR page, when DFR is enabled). Both use the same editor:
- Pick your metric from the Add a chart… dropdown. Checklist metrics sit alongside the built-in flight and incident charts, labeled with the template they came from.
- Drag rows to set the order on the page.
- Set each chart to half or full width, and pick a color per series if the default is not what you want.
- Click Save layout. The page renders exactly what the editor shows; with nothing saved, both fall back to their defaults.
Two practical notes. Metrics are keyed by template and field, so the same question on two templates makes two separate charts. And these charts cover the last 365 days of completed checklists, so a new question looks thin until responses accumulate.
Answers travel with the record outside the charts too: a flight's detail PDF includes the template name, who completed it, when, and every answer. Reports and exports covers the other export paths.
Frequently asked questions
Who can create and edit checklist templates?
Creating, editing, and deactivating templates requires Global Admin or System Admin. Everyone else can read templates, which is what lets pilots fill them in. Completing a checklist is open to any signed-in user with access to that flight's unit, and editing a completed one is limited to the person who filled it or a Supervisor and above.
What happens to completed checklists when I change a template?
Nothing. Each response stores its own snapshot of the fields as they were when it was completed, so a template edit cannot desynchronize a record from its answers. Reopening an old checklist shows the original fields and values, while new checklists use the current template. Deactivating a template also leaves existing responses intact.
Can I import post-flight checklists from AirData?
No. AirData's API exposes flights, drones, batteries, and pilots, and its per-flight CSV is telemetry only — neither carries checklist fields. Those answers live in the AirData portal and its generated reports. Flights imported from AirData arrive without checklists, so the post-flight checklist is completed here against the imported flight.
Why can't I delete the public summary question?
Because the public transparency portal reads it. While the portal is enabled, the public summary and the remove-from-public toggle are locked onto every active post-flight template, since that toggle is the only way to keep a flight off the portal. Disable the portal and both are removed automatically.
What exactly counts as an overdue checklist?
A flight that took off longer ago than the agency's completion window — 24 hours by default, configurable from 1 to 720 hours — that still has no completed post-flight checklist and took off within the last 90 days. Flights covered by a mission checklist count as complete, and what you see is scoped to your role.
Where to go next
Set your completion window and turn on the dashboard card before rolling checklists out — enforcement is what makes the data complete enough to chart. Then see flight records and maps for how checklists attach to flights and missions, the public transparency portal if your agency publishes flight activity, and reports and exports for the export paths your answers feed.