Sending a checklist to crew

Most requests ask a crew member for something: a document, an answer, a signature. A task request asks them to do something, and gives them a checklist to tick off as they go. Induction steps, a load-in procedure, what a supplier needs to have done before they arrive on site.

It is the same workflow library that produces your internal Tasks and workflows, pointed outward. You build the checklist once, and send it to whoever needs to work through it.

Tasks you do, tasks you send

Two things in 1pm are called tasks and they run in opposite directions. Worth separating before anything else, because the names are close enough to trip over.

The Tasks page in the sidebar is your own to-do list. It is internal. Crew never see it, and ticking something there tells nobody anything.

A task request lives on an event's Requests panel alongside every other thing you have asked for. Crew see it on their own link, they tick it themselves, and their progress counts toward whether they have finished their onboarding.

Same library behind both. Different audience, different meaning.

Sending one

Open the event's Requests panel and use Add from a workflow. Tick one workflow or several, and apply.

Everything you picked in one go lands in one request, with each workflow becoming a task inside it and its steps underneath. That is deliberate. You asked for one thing ("work through these"), so crew get one row rather than four, and your dashboard gets one line per person rather than four. Pick a single workflow and the request is named after it; pick several and it is called "Tasks", which you can rename inline.

You can also type a task straight into the request without going near the library. A one-off does not need to become a permanent workflow first.

Because a task request is a request, everything that works on the others works here. Make it required or optional. Put a conditional section marker above it and the whole checklist is gated to a named cohort of crew, or to how somebody answered an earlier question. Nothing special applies.

Tasks, steps, and what counts as done

There are two levels, the same two the Tasks page uses:

• A task is usually one applied workflow, named after it.
• Steps sit underneath it.

Both are tickable, but they are not both work. A task with steps is a container: its tick is a select-all over everything under it, so it is not counted as a unit of progress in its own right. A task with no steps is the work itself, so it counts.

That is why a checklist of one workflow with nine steps reads "7 of 9 steps done" rather than "7 of 10". The wording follows the shape: "steps" when everything is stepped, "tasks" when they are all bare one-offs, and "items" when you have mixed the two and neither word is true.

A task request is satisfied when every required item under it has been ticked by that crew member. Optional items still show in the count, so the number on screen always matches the lines on screen, but leaving one blank does not hold anybody up.

Two edges worth knowing:

• Partly done still reads Outstanding. A half-worked checklist is something you are still chasing, so that is what the dashboard says. The count comes with it, so "how far in are they" is answerable without opening anyone's row.
• An empty checklist is never satisfied. A task request with no items yet is your unfinished ask, not their unfinished work, so it does not quietly count as complete.

Ticks are per person. The checklist itself is one ask shown identically to everyone it is visible to; who has ticked what is tracked separately, and the planner view shows you how many have ticked each line.

Editing without breaking what people have already done

Labels are copied into the request when you apply the workflow. Editing the workflow in your library afterwards does not rewrite requests already out there, and adding a step to a workflow does not silently un-complete onboarding somebody has already finished. New steps reach an existing request only when you re-apply the workflow, which is a decision rather than a side effect.

Written procedures work the other way round. The procedure under a step is read live from your workflow library, so correcting the wording once updates every request it has ever been applied to. This is the same arrangement described in Printing your procedures manual: the procedure is stored once and read everywhere.

You can override a procedure for one request only, when this event genuinely differs. The editor tells you when the text you are reading is an override rather than the library's, so an edit here does not look like it changed the workflow for everybody. Clear the box and it falls back to the library wording, rather than blanking the procedure. Those would otherwise be the same keystroke.

Renaming a task or step changes it for this request alone, for the same reason.

What crew see

The checklist appears on their own link with the rest of their requests, in the order you set. Each line is tickable, and a step's written procedure sits under it, so somebody working through an induction reads what to do rather than guessing from a four-word title.

Ticking is theirs to do and theirs to undo. Their progress shows on their own page as they go, and lands on your Requests dashboard and the account-wide Requests page at the same time.

Related articles

• Tasks and workflows covers the internal task board and building the workflow library this draws on.
• Printing your procedures manual covers written procedures and how they are stored once and read live.
• Asking crew for documents and info covers the other request kinds and the panel these sit in.
• The Requests dashboard covers the per-event scoreboard a task request feeds.
• The Requests page covers the account-wide view.
• Using 1pm for onboarding and compliance requests covers the whole onboarding workflow this sits inside.