Tasks

A task is one piece of work someone has to do: photograph the pallet, collect a signature, count the crates, drop the paperwork at reception. Tasks are where the detail of a delivery lives, and they are the only place proof is captured. A task either hangs off a stop on a trip, or stands on its own with no trip at all.

Every task has a title and a type. The type is descriptive rather than functional — it drives the colour of the tag and the way the list reads, not the behaviour — and is one of delivery, pickup, inspection, verification, documentation or custom.

Beyond that, the fields that change how the task behaves are:

• Priority — high, medium or low. Sorts and colours the task; enforces nothing.
• Required — a required task cannot be skipped. This is the single strongest control you have over a driver’s route through a stop.
• Required proof — what the driver must capture before the task can be completed. The task form lets you pick at most one.
• Checklist — sub-items inside the task, each of which can itself be marked required.
• Contact — name, phone and email. The email becomes mandatory the moment you ask for PIN proof, because that is where the PIN is sent.
• Reference — your own identifier for the task, searchable and filterable, for tying a task back to an order or a work order in another system.

A task moves through a small, deliberately one-way state machine. There is no path back from completed or skipped, and the only way out of failed is to retry it.

When one task is really five small confirmations, use a checklist rather than five tasks. Checklist items are ordered, individually tickable, and each carries its own required flag. Optional items are there for the driver’s benefit; required items are the ones that block completion.

The choice matters operationally: a checklist keeps the stop reading as one unit of work, while separate tasks each get their own status, own proof and own row in the task list. Split into separate tasks when you want to report on them separately.

The Tasks page shows every task in the tenant, across every trip, plus the standalone ones. Three views sit behind the same filters:

• Board — lanes for Pending, In Progress and Completed, with skipped and failed collected below them. Best for moving work along.
• Table — sortable, paginated, with configurable columns. Best for auditing.
• Timeline — the same page of tasks in time order.

Above all three sits a status strip — pending, in progress, completed, failed, skipped — where clicking a cell filters the list to that status, and a set of rate measures: completion rate, on-time rate, average cycle time and proof capture rate.

The filter bar groups predicates into Classification (status, priority, type, reference), Schedule (due, updated) and Where it sits (assignee, attached to, trip, destination). Free-text search matches the title, the description and the reference.

Two filters are worth knowing about specifically. Attached to separates trip-bound tasks from standalone ones, which is the fastest way to audit either population. And Assignee matches the effective assignee — the person explicitly assigned, or failing that the driver of the parent trip — so it returns what an operator expects rather than only the explicitly-assigned subset.

If you have defined custom fields for tasks, they appear as extra columns and as conditions in the same toolbar.