Managing Tours

A tour links several properties into one multi-property patrol run: your team drives the stops in sequence and handles whatever is due at each property. The typical use case is mobile patrol in the security industry: a night round across several guarded properties, driven by one person, documented as a single continuous run.

A stop is a property. In the normal case you do not have to configure what happens there: on site the LiteLog app shows the property's open tasks and the person completes them. Only when a fixed checkpoint round should be walked at the stop instead do you add one of the property's guard tours as a detail.

Stop	What happens at the property
Without guard tour (the normal case)	The person completes the property's open tasks on site. If there are none, they only book arrival and departure.
With guard tour	The person walks the property's guard tour — scan by scan, with a log.

:::tip You assign no tasks when planning You do not pick individual tasks for a stop. On site, the LiteLog app simply shows the open tasks of the stop's property — the same ones that appear in that property's task feed anyway. There is a practical reason: between planning the tour and driving it, tasks are added and closed. A fixed assignment would already be stale by the time the team sets off. :::

Tours live in the Tasks area — there is no separate navigation item:

• Tour runs appear in the tasks list (Tasks → List). In the left panel, choose Tours under Type to see only tour runs; in the "All" view they sit next to tasks and guard tours.
• Planning — the Schedule (Tasks → Schedule) lists planned tours per day as the layer Tours (planned); clicking a tour opens the editor as a drawer over the Schedule. You reach the Schedule with only this layer via the "Go to schedule" link in the Tours type filter (when no runs fall into the period) or via the "Edit tour" pencil inside a tour run. There is no separate tour list any more; the old address /tours/plans redirects to the Schedule.

:::info The tour is the internal bracket Nothing changes at the individual property: tasks are completed as completely normal tasks, stop patrols are logged as completely normal guard tours. They appear as usual in the tasks list and in the property's route log — including in the customer portal. The tour is the bracket above them: it assigns the work to one drive, adds arrival, departure and skipped stops, and provides the overall report. :::

Creating a tour

Open Tasks → List and click "+ Create". In the drawer, choose the "Tour" button under "Add details" — the tour editor opens as a drawer over the task (your input is kept) with three sections: basic data, stops and scheduling.

Two more paths lead to the same editor:

• Type filter Tours with no runs in the period → button "New tour".
• Tasks → Schedule → "Create" → type Tour; you edit existing tours by clicking their row in the Schedule.

If you may create tours but neither tasks nor guard tours, the primary action in the header reads "New tour" directly.

Basic data

• Name — the tour's label, e.g. "Night patrol south".
• Description — optional free text.
• E-signature on completion — only visible when the digital signature is enabled for your company. "Default (tenant setting)" follows the company switch, "Always required" demands a signature from the driver when completing the tour in the LiteLog app (re-authentication via password, NFC chip or QR code), "Off" disables it for this tour. The result appears in the tour log under Signature.

Stops

First set the stop order — two modes:

• "Fixed order": the stops must be driven in the planned order. In the LiteLog app only the next open stop is active.
• "Free order": the stops can be completed in any order.

Use "Add stop" to add as many stops as needed and sort them by dragging the handle on the left or with the "Move up" / "Move down" arrows. A tour needs at least one stop. Per stop you pick the property (required) — that is all a stop needs.

Everything else is a detail you add via the chips below the property when needed (one click opens the field, the × on the field removes it again):

• Guard tour — one of this property's guard tours to run at the stop. Once the detail is open, a guard tour must be selected; otherwise the tour cannot be saved.
• Arrival from — offset in minutes relative to the tour start: from when should the person arrive at this stop? Via "Shortest route" and the travel-time suggestions, the editor can fill these values for you.
• Tolerance (min.) — minutes around the planned arrival within which the stop counts as on time.
• Note — free text for the person driving, e.g. "Use gate 3, dog on site!".

The map on the right shows the stops numbered in the planned order (straight lines, not a driving route).

When a guard tour?

• Without guard tour — the standard case. There is concrete work at the property: fixing defects, maintenance, cleaning points, follow-up checks. The only prerequisite is that tasks are maintained for the property — the app takes care of the rest. If nothing is due, the visit itself is the proof (arrival and departure are booked).
• With guard tour — when a fixed checkpoint round has to be walked and proven scan by scan, with a log for the client.

:::tip Create guard tours first The "Guard tour" detail only lists the guard tours of the selected property. How to build a guard tour with checkpoints is described in Create Route. :::

Scheduling

The "Tour active (runs will be scheduled)" switch in the card header decides whether the schedule produces runs at all: LiteLog only generates future runs for active tours. A deactivated tour keeps all its settings and can be saved without a schedule entry, but no new runs are created.

Use "Add schedule" to add one or more schedule entries — the pattern matches the scheduling of a guard tour. An active tour needs at least one entry. Per entry:

• Start date — first day of the series; days before today (in your account's time zone) are locked.
• Time window (start → end) — the run's time window, typed as text (e.g. "22:00"). If the end is at or before the start, the window crosses midnight (typical for night rounds); the editor then shows "Ends on the following day."
• Label (optional) — name of the entry. Left empty, the entry is called "Schedule 1", "Schedule 2" ….
• Recurrence — the shared recurrence controls: daily, Mon–Fri, Sat–Sun, weekly (with weekdays), monthly (with days of the month) or no recurrence (one-off); plus the holiday rule ("Treat normally", "Skip on holidays", "Only on holidays") and an optional series end.
• Notification on missed run — which automation rule runs when the run or one of its stops is missed (rules of type Tour violation (reaction workflow)). "Default" follows your tenant's reaction default Tours (Automation → Defaults). What "missed" means is described under Missed runs.

Schedule changes only affect future runs — runs already in progress or completed stay unchanged.

Saving with a reason

If a change drops runs that are already scheduled — because you remove a schedule entry, move the time window or deactivate the tour, for instance — "Save" opens the "Reason required" dialog. Enter at least five characters under Reason and confirm with "Save with reason". The reason is recorded together with the number of dropped runs in the tour's change history. Changes that do not affect scheduled runs save without a prompt.

Deleting a tour

In the tour editor of an existing tour, open the ⋯ menu in the header and choose "Delete tour". The "Delete tour?" dialog requires a reason (at least five characters); only then is "Delete" available. Future scheduled runs are dropped; completed logs are kept, and the reason is recorded in the change history. The action requires the "Delete tours" permission.

Missed runs

The server checks the scheduled runs every five minutes:

• A run that was not started by the end of its time window changes to the status Missed; all of its open stops are marked Missed as well.
• A started run that is still not completed 24 hours after the end of its window also changes to Missed. Stops already departed or skipped stay as they are; only the open stops are marked as missed.
• If a run is completed while stops are still open, those stops count as missed.

Each marking writes a line into the run's change history ("Missed at" in the log). Afterwards the rule you chose under "Notification on missed run" on the schedule entry runs — or the reaction default Tours. The bundled default rule "Bei Tour-Verstoß: Aufsicht benachrichtigen" (email, push and in-app to the first admin) is switched off for existing accounts; enable it under Automation or assign your own rule, otherwise a missed run stays without a notification. Missed runs appear in the tasks list, in the Schedule and in the LiteLog app with the status Missed.

Permissions

Tour planning has its own permissions (Settings → Hierarchy, role editor):

Permission	Effect
"View tour planning"	Makes the Tours type filter in the tasks list and the tour layer in the Schedule visible (read-only).
"Create tours" / "Edit tours" / "Delete tours"	Maintaining tours in the editor. "Edit tours" additionally covers acknowledging, correcting stop stamps and the archive request in the log; "Delete tours" covers the "Delete tour" action with reason.

By default, admin roles hold all four permissions; the property manager role can view tour planning but does not maintain it. Running a tour in the LiteLog app depends on the existing run permission "Run free and preset rounds" (RUN_TOURS) — planning and running are deliberately separate permissions.

Logs: evaluating tour runs

In the tasks list with type Tours, each row shows the tour name with stop progress ("x/y stops"), the time window, the number of properties and the status. The status moves through Planned → In progress → Completed; runs not carried through show Cancelled, runs never driven show Missed (see Missed runs). To narrow the list, use the tasks list's filter bar (including period).

Clicking a row opens the run's detail view (it slides in on the right and is directly linkable). It shows the time window, Completed at, the Acknowledged note (by whom, when) and the Signature (verification status of the e-signature, where required) plus the stop timeline: per stop

• property, mode (Tasks / Patrol / Check-in only) and status (Pending / Arrived / Departed / Skipped / Missed),
• Booked by — the person who actually booked the arrival, departure or skip (the account signed in on the device, not a claim made by the app),
• for task stops, the counter "3 of 5 tasks completed" (the app's figure at departure) and next to it "2 recorded" — the number of completions the server attributed to this stop; below it the list Completed tasks with title, time and person,
• arrival and departure with time, plus the arrival source — "via scan" (checkpoint scan at the property), "booked manually" (button in the app without a fresh location) or "booked via GPS" (button in the app with a fresh location; the coordinates are shown in the tooltip),
• the recorded reason for skipped stops, plus the driver's optional comment and proof photos,
• for missed stops "Missed at",
• for patrol stops, a link to the corresponding route log of the property.

:::note Two task counters, two statements The counter "x of y tasks completed" is the app's figure at departure: tasks completed versus tasks open on arrival at that property. The value "n recorded" counts the completions booked at the arrived stop and attributed to it on the server. Both values stay side by side; neither overwrites the other. The counter is informational and blocks nothing: your team may leave a stop with tasks still open — because material is missing, for instance. An empty counter means the property had no open task on arrival; on patrol and check-in stops it is omitted entirely. Tour runs from before the change show no counter either. :::

Acknowledging

Finished runs (Completed, Cancelled or Missed) are acknowledged by the supervisor in the header of the detail view with "Acknowledge" (permission "Edit tours"). Afterwards it reads "Acknowledged by …" with the time, and the driver sees the note "Acknowledged by the supervisor." in the LiteLog app. The acknowledgement confirms that someone has reviewed the log — a prerequisite for the archive request. No signature from the supervisor is needed; signing happens exclusively in the app on completion.

Correcting a stop

If the driver forgot a booking, the device failed or a time is wrong, correct the stop stamp in the log: the pencil on a departed or skipped stop opens "Correct stop: property" (permission "Edit tours"). There you change

• the status — Departed or Skipped; for Skipped with the "Reason for skipping" (at least three characters),
• Arrival (date / time) and Departure (date / time),
• the reason for the correction — preset "Booking forgotten", "Device failure", "Wrong time booked" or "Other", plus the reason text (at least five characters).

"Save correction" writes the change with old and new value, person, time and reason into the change history and re-derives the run status. The rules of the time-tracking correction apply: corrections are possible up to 30 days after the end of the time window (a later attempt is rejected and logged as a rejected attempt), times must not be in the future, the departure must not be before the arrival, and archived runs can no longer be changed.

Archiving

Completed and acknowledged runs can be proposed for archiving via the ⋯ menu of the detail view with "Request archiving" — with a reason, following the four-eyes principle as for incidents and reports: the request only takes effect once a second person approves it. Runs that are not acknowledged are rejected by the server ("Tour run has not been acknowledged yet"). Archived runs carry the Archived note, remain readable and exportable, but can neither be corrected nor acknowledged.

Rejected events

If the server rejects an event from the app — for example because the account was switched before uploading, because a stop was outside the user's access, or because the event no longer matched the stop's state — it does not disappear. The detail view then shows the hint "n rejected events"; expanded, you see per event the action (arrival, departure, skip, completion), the time and the reason for the rejection, such as "Account does not match the login". This keeps the record complete even when an event was not taken into the log.

Change history

At the end of the detail view sits the change history — for the tour's plan (created, changed, dropped runs with reason, deleted) and for the run (corrections with old and new value, missed markings, archiving). Every line carries person, time and reason. The history can be neither edited nor deleted.

Exporting the tour report

Via "Download tour report" — on the list as well as in the detail view — you export the tour report as PDF or CSV. Per run the report contains Started by, Acknowledged by / Acknowledged at and the Signature, and per stop Recorded by (with staff no.), Stop type, arrival source, Tasks done / Tasks total and the Comment. The export requires the export permission (in the role editor: "Export round evaluation"). Like all exports, the generated files also appear under My Exports.

:::tip Traceability according to ALCOA+ Booked-by per stop, mandatory reasons for changes, corrections and deletions, acknowledgement, signature on completion, missed-run detection, visible rejected events and an immutable change history: tour logs thereby meet the same requirements as time tracking, guard tours and incidents — see Data Integrity & ALCOA+. :::

Tours in the Schedule

The Schedule under Tasks shows tours as their own layer: Tours (planned) from the tour's timetable, Tours (driven) from the logs. Because a tour is not bound to one object, the object column reads "3 objects" with the stop order in the tooltip, and in the objects × days matrix the tour counts at each of its stops. Clicking opens the tour editor (planned) or the tour log (driven).

Running tours in the LiteLog app

How a scheduled tour appears on the app dashboard, how starting works (internet needed once, offline afterwards), how arriving, completing tasks, walking a patrol, departing and skipping work per stop and how completion — with a signature where required — works is described in Running a Tour (App).

What changes for existing tours

Earlier versions of the editor had a mode per stop ("Tasks", "Patrol", "Check-in only"). The mode is gone as a choice — a stop without a guard tour completes the open tasks, and a stop without open tasks is automatically the plain check-in. For your existing tours this means:

• Stops with a guard tour show the "Guard tour" detail opened. Nothing about how they run changes.
• Stops that were set to "Check-in only" become normal stops the next time the tour is saved (the property's open tasks, otherwise just arrival and departure).
• Completed tour logs stay untouched; they still show the mode the stop was driven with.