Skip to main content
LLMs.md

Running a Tour (App)

A tour is a patrol run across several properties: you drive to the stops one after another and handle whatever is due at each property. Tours are planned in the portal (Managing Tours); they are driven exclusively in the LiteLog app.

Every stop carries a mode — it tells you what to do at the property:

ModeWhat you do at the property
TasksYou complete the open tasks of this property. The app shows them to you on site.
PatrolYou walk the property's planned guard tour.
Check-in onlyYou only book arrival and departure.

An upcoming tour appears on the dashboard as one row with the "Tour" badge and the progress "x/y stops". The guard tours of the individual stops deliberately do not appear as separate feed entries — progress is tracked on the tour row; you see the stop guard tours inside the tour view. Tap the row to open the tour screen.

:::info Prerequisite Driving a tour requires the run permission "Run free and preset rounds" (RUN_TOURS) — the same right as for guard tours. Planning tours is a separate portal permission. :::

Starting the tour

The tour screen shows the tour with its time window, the order mode ("Fixed order" or "Free order") and the stop list. With "Start tour" you take over the run.

  • Starting requires an internet connection once ("Starting a tour requires an internet connection."). Right after the start the app preloads all stop properties for offline use ("Preloading properties for offline use …") — after that the tour also works without a connection.
  • Only one tour can run at a time ("Another tour is already running — please finish it first.").
  • If someone else takes over the same run first, the app reports "This run is already being led by someone else."

If a property could not be preloaded, the affected stop shows the hint "Property not preloaded — the guard tour needs internet here." — arriving, departing and skipping still work offline there; only the guard tour itself needs a connection at that stop.

Working through the stops

The stop list follows the planned order. Each stop shows the property, its mode (Tasks, Patrol with the name of the guard tour, or "Check-in (no guard tour)"), any note from planning and its status: Open → Arrived → Done, or Skipped.

With "Fixed order" only the next open stop is active; the following ones are locked ("Order is fixed — finish the previous stop first."). With "Free order" you pick the stops in any sequence.

Arriving

You book the arrival at a stop in two ways:

  • "Arrive" button on the active stop. If the app has a fresh location (less than a minute old), it books the arrival via GPS and stores the coordinates with it — recorded as "booked via GPS" in the log. Without a fresh location the log reads "booked manually".
  • Automatically via chip scan: scan a checkpoint of the stop's property and the app books the arrival by itself — recorded as "via scan" in the log.

Every booking carries the person who triggered it in the log ("Booked by") — this is always the account you are signed in with in the app.

Task stop

After arriving, the app shows you the open tasks of this property — the same ones that appear in the property's task feed anyway. You work through them as usual: tap, complete, add a photo or fill in a form where required. When you are done, tap "Depart".

  • Nothing was assigned during planning. The list is built on site and always reflects the current state — including tasks added after the tour was planned.
  • The stop counter in the portal is informational: you may depart with tasks still open. Whatever you do not manage stays open and is there again next time.
  • If the property currently has no open task, the stop is a short visit: "Arrive", "Depart".
  • Tasks you complete at the arrived stop are attributed to that stop by LiteLog. In the tour log the value "n recorded" then appears next to the app's counter, with the list of completed tasks below it.

:::tip Tasks with "Complete only at checkpoint" If a task carries the "Complete only at checkpoint" option, you can only complete it after scanning a linked checkpoint — inside a tour as well. That scan also books your arrival at the stop. :::

Patrol stop

After arriving, start the planned guard tour via "Start guard tour". It runs like any guard tour — the app switches to the stop's property for it, including that property's usual time-tracking prompt, and you work through the checkpoints. As soon as the guard tour ends, the app books the departure automatically and the stop counts as done.

Check-in stop (no guard tour)

A check-in stop consists of two bookings: "Arrive" and "Depart". This documents the visit without any further work at the property.

Skipping a stop

If a stop cannot be reached, tap "Skip". In the "Skip this stop?" dialog the reason is mandatory — no reason, no booking. Optionally add a comment (optional) and, via "Take photo", one or more proof photos, of the locked gate for instance. The app logs the stop as skipped; reason, comment and photos appear in the tour log in the portal.

Completion

Once all stops are done or skipped, the app shows the "Finish tour" card ("All stops are done. Finish the run now."). With "Finish" you end the run.

  • If the tour requires a signature (the tour's "E-signature on completion" setting or the company switch of the digital signature), the hint reads "All stops are done. You sign off the run." After "Finish" you confirm your identity as when submitting a form — via password, NFC chip or QR code. The signature is stored with the completion and shown in the portal under Signature.
  • Afterwards the "Tour completed" summary appears: done and skipped stops ("x stops done · y skipped") plus the duration of the drive. As soon as the supervisor has acknowledged the run in the portal, it additionally reads "Acknowledged by the supervisor."
  • If the server did not accept an event — for example because the account was switched before uploading — it is not lost. The summary shows "The server rejected n event(s) — the supervisor sees them in the log." The supervisor finds these events with their reason in the tour log under "n rejected events".

If the tour is not driven or not finished in time, the server marks the run as Missed — the time window passed without the tour being started, or a started run was still open 24 hours after the end of the window. Missed runs show the status Missed on the tour row; the supervisor receives a notification depending on the rule (Missed runs).

Working offline

After the start the tour works without a connection: arriving, departing, skipping and the completion are buffered locally and transferred automatically as soon as the app is back online — proof photos are uploaded before the event. The guard tours of preloaded properties run offline as usual. Only the tour start itself needs a connection. If you switch accounts before the transfer, the server rejects the buffered events; they remain visible as rejected events (see Completion).

For task stops the usual offline rule for tasks applies: the app keeps the tasks from the sync window locally and completes them without a connection too. Tasks outside the sync window, or created shortly beforehand, only become visible after the next sync.

What the customer sees

At the individual property nothing changes: tasks are completed as normal tasks, stop patrols are logged as normal guard tours — they appear in the property's route log and in the customer portal like any other guard tour. The tour is the internal bracket above them; the evaluation of the whole run with stop timeline, acknowledgement, correction and tour report lives in the portal in the tasks list with type Tours.