Tasks¶

Info

Tasks and Task lists are stored in the account manifest. The Tasks feature is enabled per account by Output Industries (the enableTasks flag). When it is off, the Tasks admin, Task History and the tablet Tasks screen are hidden entirely, and nothing about existing Tasks or their station assignments is changed — turning it back on restores everything.

Context: ¶

Tasks are recurring procedures operators complete on the tablet — startup checklists, quality inspections, a reading taken during a breakdown. Each completion is recorded against the station, the operator and the moment it was pending, so there is an audit trail whether or not the operator ticks it off.

Tasks are organised into Task lists. The list is the unit that matters: it decides how often its Tasks are pending, which stations see them, and how they are grouped on the tablet.

Importance: ¶

A Task turns a paper checklist into a record Busroot can report on: which checks were done, which were missed, and any reading the operator entered with it.

Task lists¶

Task lists are managed on their own admin page. A list has a code (read-only once created), a name, a description and a trigger. The Task List Management table shows all four, with the trigger reading Each Schedule, On Demand or Timer followed by its cron pattern (Timer: 0 9 * * *) — the same wording as the Trigger column on the Task table.

Trigger¶

Every Task in a list follows the list's trigger — a list cannot hold a mixture.

Trigger	When its Tasks are pending
Each Schedule	Once per production schedule. The Tasks become pending shortly after the schedule's actual start, not its planned start: when the operator starts it on the tablet, or at the planned start time for a schedule set to start automatically. A schedule that is planned but not yet started has no pending Tasks. They are missed if the schedule ends (or is deleted) without them, if another production schedule is started on the station while it is still running, or if the schedule is moved to another station.
Timer	At every fire of a cron pattern, evaluated in the plant's timezone. The fire is the deadline. Available Before Deadline controls how long before the deadline the Tasks become pending and appear on the tablet — a weekly check due Friday 17:00 can be made available only from Friday morning. A Task not completed by the fire is missed. The options offered are always shorter than the shortest gap between fires in any of the account's plant timezones, so a Task can never be available for two periods at once. Changing the pattern clears the selection so it is re-chosen against the new pattern.
On Demand	No deadline. The list is started by the operator whenever circumstances demand it — the checks performed during a breakdown, say — which makes every Task in it pending; each is then completed individually and the list can be started again straight away. On Demand Tasks are never missed for time; they count as pending from when the list is started until each is completed. A run that is still open when its Task is deleted, its list is removed from the station, or the station is archived is marked Missed at that point, so nothing stays pending for ever.

Any list, whatever its trigger, can also be started by the operator from the tablet (Start this List). A run started this way is an On Demand instance: it has no deadline, is never missed, and is recorded in Task History as On Demand. An Each Schedule or Timer list still becomes pending on its own. If that happens while the manual run is still open, the run becomes the scheduled instance: it keeps its place on the tablet, takes the deadline (Timer) or the schedule, is recorded in Task History under that trigger with the time the list was started as its Created At, and is missed like any other scheduled instance if it is not completed in time. If the scheduled instance is already open when the list is started, that instance is simply the one the operator completes; if it has already been completed, the manual run stays On Demand.

Deleting a list is never blocked. It is removed from every Task that belonged to it and from every level that included it, in one step. A Task left in no list disappears from every station until it is added to another one.

Task settings¶

Code, Title, Description¶

The code is the permanent identifier (letters, digits, - and _, up to 32 characters, stored in upper case). The title (up to 128 characters) is what operators see on the tablet; the description (up to 300 characters) explains the procedure. Tasks created before these limits were introduced keep working, but must conform when next saved.

Task Lists and Order¶

A Task must belong to at least one Task list, and may belong to several. Membership is what gives a Task its trigger and what puts it in front of an operator — a Task in no list appears nowhere.

Under Order, each selected list gets a number box: "Set the order the task will appear in each list. Use decimals to insert between existing positions (e.g. 1.5 between 1 and 2)." Adding a Task to a list fills in the next whole number for that list, so ordering always exists without having to invent one. The number controls where the Task sits within that list on the tablet and in the Task table. Every selected list must have an order when the Task is saved — a cleared box is flagged rather than silently refilled, and a Task created before ordering existed is asked for one the first time it is edited.

An order must be greater than 0 and at most 100. A list already using 100 keeps offering 100 as the next number, so two Tasks can share it — they then hold their existing relative order, and can be separated with a decimal. Orders stored above the cap from before it existed keep working and only have to conform when the Task is next saved.

A Task in two lists is a Task with two lives. It follows each list's own trigger, and it must be completed separately in each — completing the breakdown-checklist copy does not tick off the daily-checks copy, even a second later. Use this deliberately, for a check that genuinely belongs in two contexts.

Require Notes¶

When on, the operator must enter a note before the Task can be completed — for readings and measurements a tick alone cannot capture (a dew point, gun hours). The note is stored with the completion and shown in Task History. This is set per Task, not per list: it is about what the operator records, not about timing.

The Task table¶

The Task Management table has a Filter by List dropdown, defaulting to All. Selecting a list shows only that list's Tasks, in that list's order. The Task Lists, Trigger and Order columns line up position for position, so a Task in two lists reads across as "Daily Checks · Breakdown Checklist" / "Timer: 0 9 * * * · On Demand" / "3 · 1". The dropdown reads No Lists and is disabled when the account has no Task lists.

Which stations get a Task¶

Task lists are assigned to stations through the same include/exclude cascade as reasons — the Task Lists panel on the Account, Plant, Station Group and Station forms. A Task reaches a station when one of its lists is included for that station.

Nothing is included by default

Unlike reasons, no Task list is available until one is explicitly included at some level. A newly created list reaches no station until it is included on the Account, Plant, Station Group or Station form. This is deliberate: adding a Task can no longer put it on every tablet in the company by accident.

See How Manifest Settings Drive Busroot.

The Task List Management page has an Availability column showing how many stations each list actually reaches — "All stations", "8 of 12 stations" or "No stations" — out of every station in the account except archived, scheduling-only and meter-only ones. Hover the count to see which Account, Plant, Station Group or Station lists mention it, each tagged Included or Excluded; the same breakdown, with the full hierarchy path of every mention, appears as a read-only Availability panel at the bottom of the list's edit form. A list nothing mentions reads as "No stations", which is the default described above.

A Task cannot be deleted while a SKU still references it.

Task History¶

The Task History page lists every instance of every Task with its status:

Completed — done, with who completed it and when.
Missed — the deadline passed (Timer) or the schedule ended, was deleted, was moved to another station or had another production schedule started after it on the station (Each Schedule) without a completion, or an On Demand run was still open when its Task, list or station assignment was removed; Missed At says when.
Pending — still open: the deadline has not passed, the schedule is still running, or the list has been started by the operator and this Task not yet completed.

There is one row per Task per list, and the Task List column says which one it belongs to — so a Task in two lists is audited separately in each. An instance appears the moment it becomes pending — a Timer Task when its availability window opens, an Each Schedule Task shortly after the schedule actually starts, any Task when its list is started from the tablet — so the audit trail exists whether or not operators tick things off. Expected At is the deadline and is only set for Timer instances; Created At is when the instance became pending. An instance started from the tablet is recorded as On Demand whatever its list's trigger (unless the scheduled instance adopts it, above), and On Demand instances are only Missed when orphaned. Columns include the Task, its Task list, trigger, the station, the operator, and any note entered on completion; the table can be exported to CSV, and the date range selects instances by when they became pending. Filter by List above the table narrows it to the instances recorded under one Task list; it applies straight away, without Submit. Instances recorded before Task lists existed, or under a list that has since been deleted, only appear under All.