Search the documentation

Find a page by title or section.

Tasks and proof

Standalone vs. stop tasks

A task can hang off a trip stop or stand on its own. What changes between the two, and when to use each.

Updated

Tasks started life bolted to trip stops, and most still are. But a task no longer needs a trip: it can be assigned straight to a person, with a destination and a due date and nothing else. Both kinds are the same object with the same statuses, the same checklists and the same proof — what differs is where the task hangs, and therefore where the work gets done.

Side by side

Stop taskStandalone task
What it hangs offOne stop on one tripNothing — no trip, no stop
Who does itWhoever is driving the tripA named assignee, required at creation
Assignee can beThe trip’s primary or secondary driverAny active user in the tenant
LocationInherited from the stopAn optional destination link
TimingThe stop’s window and sequenceAn optional due date
Order enforcementOptional, per stopNone — nothing to order it against
Where the driver works itInside the trip, at the stopFrom the tasks list, any time
PIN proof is sentWhen the trip startsAs soon as it is created or assigned
Available by defaultYesNo — switched on per tenant
The differences that matter operationally. Everything not listed here is identical.

Stop tasks: work that belongs to a journey

A stop task is the default and the right choice whenever the work only makes sense once the driver is standing at the address. It inherits everything about where and when from its stop, so there is nothing extra to fill in.

Two behaviours only exist here. A stop can enforce task order, in which case a task refuses to start or be skipped while any lower-sequence task on the same stop is still open — useful when the inspection genuinely has to happen before the handover. And cancelling or skipping the stop cascades: its pending tasks are skipped with it, required or not, because there is no longer a visit in which to do them.

Stop tasks can also be created in bulk rather than one at a time — from a task template, or automatically from the destination’s own default task list.

Standalone tasks: work that belongs to a person

A standalone task is for work that has an owner and a deadline but no journey: chase a missing signature, collect a document from a site tomorrow, photograph damage reported after the fact. The assignee is mandatory — it is the only anchor the task has — and it can be any user in the tenant, not just a driver. An admin can hold a task themselves.

A destination link and a due date are both optional. The destination gives the task an address without inventing a trip for it, and makes the task appear on that destination’s own record.

Creating a standalone task once the setting is on.

  1. 1

    Turn standalone tasks on

    Customization → Operations → Standalone Tasks

    One tenant-wide switch. It adds the create button to the tasks list and to the driver and destination records.

  2. 2

    Start a new task

    Tasks → Add Task

    You can also start from a driver’s or a destination’s Tasks tab, which prefills and locks the corresponding anchor.

  3. 3

    Choose an assignee

    Search picks from active users in your tenant. This field is the one thing the task cannot be saved without.

  4. 4

    Add a destination and a due date, if they apply

    Both are optional. A due date is what makes the task eligible for the Overdue and Due today quick views.

  5. 5

    Fill in the task itself

    Title, type, priority, required flag, required proof, checklist and contact behave exactly as they do on a stop task.

What the driver sees

This is the difference drivers actually notice. In the mobile app, a standalone task is marked Direct and is worked from the task screen itself: start it, tick the checklist, capture proof, complete it.

A trip-bound task opened from the same list is read-only, with a note pointing at the trip and a button to open it. That is deliberate — completing it needs the arrival and stop context the trip screen has and the task screen does not.

Choosing between them

  • The work happens at a stop, during a run — stop task. Do not create a trip purely to hold a task.
  • The work has an owner and a deadline but no route — standalone task.
  • The work must be done in a fixed order alongside other work at the same address — stop task, with enforce task order on the stop.
  • The owner is not a driver — standalone task; a trip cannot be assigned to an admin.

Terminology

Your organisation can rename these. If your screens say something else, this is what they mean here.

Task
One unit of work with a status and, optionally, required proof. Some tenants call these jobs or actions.Rename it in Customization → Terminology
Stop
One ordered visit within a trip. A trip-bound task is anchored to exactly one of these.Rename it in Customization → Terminology
Driver
The person carrying out a trip. A standalone task, unlike a trip, can be assigned to any user.Rename it in Customization → Terminology