Skip to main content
LLMs.md

Tamper protection

What is this view for? Here you define, per property, how LiteLog verifies that actions really happened on site — the location verification. Without verification, a clock-in, incident, or task could in theory be submitted from anywhere; with verification, the app blocks actions that do not happen on site.

Navigation (portal): Master data → Properties → select a property → panel entry "Tamper protection" (group "Administration")

Navigation (LiteLog app): Administration → Property settings → "Tamper protection"

The three areas​

The page bundles verification for three feature areas. For each area you pick one method:

AreaWhen is it checked?Available methods
Time trackingWhen clocking in and outOff · Geofencing (GPS) · Beacon
Incidents & FormsWhen submitting an incident or formOff · Geofencing (GPS)
Tasks & ToursWhen booking checkpoints and completing tasksOff · Geofencing (GPS)

You can maintain the same three verification settings directly in the features Time tracking ("Proof" section), Incidents & Forms (location lock) and Rounds (location lock); there they are saved together with the respective card. This tab remains the overall view of all three areas with the latest verification events — both places control the same setting.

The methods in detail​

Off​

No location check. Actions are possible from anywhere.

Geofencing (GPS)​

When the action is completed, the app checks whether the device is inside the property's location area (the shape from the map assistant, with a tolerance buffer against GPS drift). Outside the area — or when no location can be determined — the action is blocked and the app shows a notice.

:::caution Prerequisite Geofencing needs a drawn property area and the app's location permission. Without an area, the check blocks with "location unknown". :::

Beacon (time tracking only)​

Clocking in/out is only possible near one of the property's location verification beacons — ideal for fixed clock-in spots indoors (entrance, basement, underground garage) where GPS is unreliable. The server additionally validates the proof and stamps a trust level on every booking.

You bind beacons in the LiteLog app: Administration → Connect beacons → "Location verification". The same beacon also greets arriving staff with a clock-in hint and switches the active property automatically.

What about tours with beacons?​

There is deliberately no separate beacon verification for tours: bind the checkpoints themselves as beacons instead. Every booking then physically happens at the beacon — automatically verified at the point, with no extra setting. NFC chips and QR codes achieve the same because they can only be scanned right at the point; this page's GPS geofencing complements both at the property level.

Additional plausibility flagging​

Regardless of the chosen method, LiteLog flags individual events when something contradicts the reported position:

  • Mock location — The device reported the position as simulated (fake-GPS app active). Only Android provides this signal; iOS and older app versions provide no assessment.
  • Implausible location change — Two time-tracking bookings of the same account are so far apart that the move was physically impossible in the available time.

Flagged events appear with a red icon and explanatory tooltip in the timeline of the work time detail view and on the respective scan in the tour protocol. Two things to keep in mind: an event without a flag is not proof of integrity (the signal is not available on every device), and a flag is a suspicion indicator, not proof — always assess it in context. The reliable on-site proof remains capture via NFC, QR or beacon. To be actively notified about flags, enable the rule for the "Manipulation suspicion (mock GPS / implausible travel)" trigger under Automation.

Event list: who was denied, and when?​

Every denied, bypassed or flagged booking attempt is logged and visible in two places: as the "Recent events" card directly on this page (the most recent events of this property) and in full in the Activity view via the Tamper protection chip. The Activity view additionally offers the Suspected tampering section — a per-person repetition report across all properties.

Digital signature​

Below the event list sits the Digital Signature card — it only appears when the bookable feature has been unlocked for your account. While the location proof above establishes where a booking took place, the digital signature establishes who triggered it: employees re-confirm their identity when submitting an incident report, submitting a form or completing a task (re-authentication per 21 CFR Part 11).

Per area (incident reports, forms, tasks) you choose Off or Required; under Allowed methods you define what may be used for signing (password, NFC chip, QR code, PIN). If tasks is set to Required, the Create Task form for this property shows the "Digital signature" section by itself with the note "From object: required" — the task inherits the requirement without any further setting. The card saves independently of the location card via its own save button. What the signature provides, how the cascade of company switch, property and template works together, and what the signature log looks like is described under Digital Signature.

Good to know​

  • The setting applies per property and is off by default — existing properties do not change behavior until you actively choose.
  • Blocked actions show the employee a clear notice ("Outside the property" or "Beacon out of range") — nothing is lost; the action can be repeated on site.
  • If Bluetooth is unavailable on the device, the beacon check never locks anyone out; the booking is instead flagged server-side as "without proof" and stays auditable.