Automation — Rules
You reach the automation area via the Automation tile in the Tools group at the bottom of the sidebar — it is available there from every main area. The entry point first opens the Notifications overview: it shows the resolved outcome per event area ("What happens — and who receives what?") and contains the reaction defaults. The Rules menu item behind it is the hub for rule-based notifications and follow-up actions. Every rule follows the if-then pattern: a trigger (e.g. "Patrol missed"), optional conditions, and one or more actions. LiteLog does not prescribe fixed processes: you automate your own procedures and adapt them to your company — triggers, conditions, and actions are freely combinable building blocks. The rules overview shows at a glance which rules are active, who is notified, and via which channels.
Features Overview
Rules Table
Each row is a rule. Besides name and trigger, the table shows two key columns:
| Column | Content |
|---|---|
| Recipients | Who is notified — role and person badges |
| Channels | How they are notified — email, SMS, call, push, in-app |
Use the toggle in the row to enable or disable a rule without deleting it.
Template Gallery
As long as the rules list is empty, the page shows a gallery of ready-made if-then chains from real-world practice, filterable by trigger area (e.g. round, incident, form, attendance, safety, task). Each card shows the rule's chain as a preview. Once rules exist, you reach the same templates in the workflow editor via "Use template". There are two ways to adopt a template:
| Button | What happens |
|---|---|
| Activate | For simple templates that already have an included (disabled) default rule: the existing rule is switched on directly — without a duplicate. |
| Set up | Opens the workflow editor with the fully assembled chain as a draft. You adjust recipients, wait times, and scope, then save. |
Templates that use building blocks from the larger packages carry a lock icon; templates with SMS or call carry an "SMS" badge (SMS add-on required).
These 14 chains are ready to use in the gallery:
| Template | What it does |
|---|---|
| Missed round → email | Notifies the property email addresses when a planned round was not performed. |
| Missed route → escalation | Informs the property assignees by push and escalates by email to management after 30 minutes without acknowledgement. |
| Patrol starting soon → push | Reminds the property assignees by push before the planned round (lead time configurable). |
| Missed checkpoint → incident | Automatically creates an incident when a checkpoint was not scanned and emails the property assignees. |
| Incident → AI triage → escalation | Classifies new incidents with AI; on high urgency the team is notified and, after 30 minutes without acknowledgement, the case is escalated to management. |
| Incident → AI triage → task | Classifies and, on high urgency, automatically creates a high-priority task; the object team receives a push. |
| Incident → claim offer to the team | Offers the incident to the object team; if nobody takes it within 15 minutes, management is informed by e-mail. |
| Detected defect → task | Turns a defect detected in a form into a task, e-mails the property assignees and escalates after 30 minutes if the defect stays open. |
| QA score below threshold → escalation | Notifies when a quality inspection falls below the pass threshold, creates the re-clean task, and escalates to management after 30 minutes if the complaint stays open. |
| Attendance not met → escalation | Reports an unmet attendance requirement and escalates after 30 minutes if it remains open and unacknowledged. |
| Missed check-in → SMS to supervisors | Reports a missed check-in by SMS to the supervisor numbers and by push to the property assignees; escalates after 30 minutes if still open. |
| Welfare-check alarm → call chain | On a proof-of-life main alarm, immediately triggers call and SMS to the supervisor numbers, emails the property assignees, and escalates to management after 15 minutes while the alarm stays active. |
| Emergency status → alert management | Immediately alerts management by call, SMS, and push when an emergency is reported. |
| Overdue task → management | Informs management by email and in-app message as soon as a task becomes overdue. |
:::caution None of this runs out of the box Without your input, an incident report is captured, classified (if AI classification is switched on) and placed in the list — nothing else happens. Escalation is always a rule that you have to arm via Activate or Set up. :::
New Rule
The "New rule" button opens the workflow editor as a full page. There you build the rule graphically from trigger, conditions, and actions. Clicking an existing rule opens the same editor for editing.
Triggers
Rules react to events from all areas:
| Area | Triggers |
|---|---|
| Patrols | Patrol missed, patrol completed, round starting soon, checkpoint missed, checkpoint scanned |
| Incidents | Incident created, incident classified |
| Forms | Form submitted, defect detected, form score below threshold, form signal, approval requested, report approved, report ignored |
| Attendance | Shift ended, check-in missing, check-out missing, attendance requirement failed, minimum duration not met, visit spacing violated, scheduled shift starts/ends, shift assigned/changed, no work time for N days, property area left, restricted zone entered, zone dwell time exceeded, location tracking interrupted, manipulation suspicion (mock GPS / implausible travel) |
| Absences | Sick report received, sick report decided |
| Tasks | Task completed, task overdue, task assigned, task due |
| Material | Material below minimum stock, material request received, material request decided, material not returned after shift end |
| Safety | Proof-of-life overdue (pre-alarm), proof-of-life main alarm, proof-of-life undeliverable, SOS/emergency triggered |
| Service | Service level breached |
In addition, each area has an umbrella trigger marked "(reaction workflow)" — e.g. Attendance violation or Incident reaction. Rules on these triggers do not fire directly on individual events; they are assigned via the reaction defaults (or a direct link on a requirement, property, or template): one rule then covers all violations of its area.
Missed and Upcoming Rounds
Two triggers are especially useful for rounds:
- Patrol missed — notifies you when a planned round was not performed within its time window. The rule "Missed round → email" is created active for new accounts; adjust recipients and channels in the rule editor. If the missed round is acknowledged in the log, further escalation notifications stop.
- Round starting soon — reminds the recipients before a planned round starts. You set the lead time in minutes per rule in the workflow editor — so the reminder arrives e.g. 15 minutes before the time window.
- Checkpoint missed — reports individual unscanned checkpoints of a started round after the time window expires. If the round was never started at all, only "Patrol missed" fires instead — so you do not get a point-by-point flood on top of the missed notification.
Assignment Planning & Sick Reports
Three triggers connect automation with staffing planning and absences:
- Shift assigned/changed — fires when the staffing of a shift changes. With the recipient type "Person from the event" you inform exactly the affected person about their new or changed shift.
- Sick report received — fires on every new absence report (self-report from the app or recorded by a manager), informing the managers.
- Sick report decided — fires after approval or rejection, notifying the affected person ("Person from the event") about the outcome.
For the two sick-report triggers, default rules are shipped that — unlike most default rules — are delivered active: without an active rule, nobody would notice an incoming sick report, and the decision notification promised in the app would never arrive. You can adjust or switch off both rules under Automation. The rule for "Shift assigned/changed" and the task bridge remain deactivated opt-in templates.
For shift triggers there is also the recipient type "Today's shift staffing" (all people planned for the shift today), and the "Assign task" action offers the mode "Today's shift staffing" — the task automatically goes to the person(s) planned for that day.
Scheduled Times, Shift End & Inactivity
Three attendance triggers are easily confused:
- Scheduled shift starts / Scheduled shift ends — fire at the planned start or end time of an assignment from staffing planning, regardless of whether anyone checked in or out. The right triggers for reminders like "please check in" or "please check out".
- Shift ended — by contrast, fires only on the actual check-out of a work time. The right trigger for follow-up actions after the real end of work, e.g. the material return check.
- No work time for N days — a daily check (once per day, in the morning) reports employees whose last recorded work time is at least N days ago. You set the day threshold on the trigger card (1–365, default: 10). Each person is reported only once per inactivity period and threshold; the trigger fires again only after new work time followed by renewed inactivity. People assigned to "All properties" are reported at the property of their last work time.
Geofence Triggers
Four triggers react to geofence zones — they only fire during a running shift:
- Property area left — a checked-in employee has left the property area or a zone with an active leave warning (confirmed server-side, typically 1–2 minutes after leaving).
- Restricted zone entered — a checked-in employee has entered a zone marked as a restricted zone.
- Zone dwell time exceeded — a checked-in employee has stayed in a zone continuously for longer than the maximum dwell time configured on the zone; fires exactly once per stay.
- Location tracking interrupted — the app's position stream broke off during the shift (e.g. screen switched off); in this case the system deliberately does not check the employee out automatically.
Besides the usual recipient types, the affected employee themselves is available as a recipient — so the warning can, for example, go directly to the person who left the premises.
Manipulation Suspicion (Location)
The "Manipulation suspicion (mock GPS / implausible travel)" trigger fires when a position report was flagged as suspicious — either because the device itself reports a simulated position (mock GPS, the signal is only provided by Android) or because the travel since the previous report was physically implausible (see manipulation protection). Use the Reason condition field to narrow the rule to one of the two suspicion types, and Source to restrict it to shift stampings or patrol scans. Important context: this is an indication of suspicion, not proof — and conversely, an event without a flag is no proof of innocence (iOS does not provide the mock signal). Always review suspected cases in context before drawing consequences.
Form Signal
The "Form signal" trigger fires for every signal raised by a submitted form; use the Signal type condition field to narrow the rule to a specific type. Signals of type defect additionally fire the "Defect detected" trigger — so do not set up both rules unfiltered, or you will be notified twice.
Material
Four triggers connect automation with the material module (relevant only with the module enabled):
- Material below minimum stock — fires when an item's stock at a property or in a warehouse falls below the minimum; target quantities and the alert apply per warehouse, and the notification names the warehouse as the location. The trigger fires once per shortfall episode: exactly one event at the downward crossing, no repetition on every further booking below the threshold; only when stock recovers to or above the minimum and drops again does a new episode begin. A booking that pushes the computed stock negative does not raise an alarm — that state is called "count needed" and is healed by a count. The bundled default rule "Material unter Mindestbestand → E-Mail" (to the first admin) ships disabled; switch it on via the toggle in the row and adjust recipients and channels in the rule editor. Condition fields include item, stock and minimum stock.
- Material request received — fires on every new material request (from the app, portal or customer portal), informing the responsible people. Condition fields include requester and note.
- Material request decided — fires after approval or rejection, notifying the requester ("Person from the event") about the outcome. Condition fields include status and requester.
- Material not returned after shift end — fires when a shift ends but the person still holds units (e.g. keys). The default rule "Material nicht zurückgegeben → Mitarbeiter" ships active and reminds the person themselves via push/in-app.
For the two request triggers, two default rules are bundled — incoming requests to the first admin (email/push/in-app), the decision to the requester (push/in-app) — but they ship deliberately disabled: the approval inbox under Material → Requests is the primary working surface; switch the rules on via the toggle in the row when needed.
Included Default Rules
A set of more than 40 default rules is created for every account. Most of them are deactivated templates that you switch on via the toggle in the row; more than a dozen are active from the start — above all the reaction default workflows (second table below) as well as the rules for missed patrols, sick reports, material not returned and review requests (rule names are shipped in German):
Event rules
These rules react directly to individual events:
| Default rule | Trigger | Recipients | Channels | Active from start |
|---|---|---|---|---|
| Verpasster Rundgang → E-Mail | Patrol missed | Property assignees | Yes | |
| Fehlende Kontrollpunkte → E-Mail | Checkpoint missed | Property assignees | — | |
| Kontrollpunkt mit Foto gescannt → E-Mail | Checkpoint scanned (condition: photo attached) | Property mail addresses | — | |
| Meldung erstellt → E-Mail | Incident created | Property assignees | — | |
| Meldung erstellt → Push an die Aufsicht | Incident created | Supervision with incident visibility | Push | — |
| Keine Arbeitszeit seit 10 Tagen → E-Mail | No work time for N days (default: 10, adjustable) | Property assignees | — | |
| Lebendmeldung nicht zustellbar → E-Mail | Proof-of-life undeliverable | Property assignees | — | |
| Lebendmeldung Hauptalarm → E-Mail | Proof-of-life main alarm | Property assignees | — | |
| Notfall-Status → E-Mail | SOS/emergency triggered | Property assignees | — | |
| Service-Level gerissen → E-Mail | Service level breached | First admin | — | |
| Material unter Mindestbestand → E-Mail | Material below minimum stock | First admin | — | |
| Schichtbeginn → Mitarbeiter benachrichtigen | Scheduled shift starts | Property assignees (role Mitarbeiter) | Email, SMS, call, push, in-app | — |
| Schichtende → Mitarbeiter benachrichtigen | Scheduled shift ends | Property assignees (role Mitarbeiter) | Email, SMS, call, push, in-app | — |
| Anwesenheitspflicht nicht erfüllt → Aufsicht | Attendance requirement failed | Supervision (property/attendance contacts); push/in-app to property assignees | Email, SMS, call, push, in-app | — |
| Check-in verpasst → Aufsicht | Check-in missing | Supervision (property/attendance contacts); push/in-app to property assignees | Email, SMS, call, push, in-app | — |
| Check-out verpasst → Aufsicht | Check-out missing | Supervision (property/attendance contacts); push/in-app to property assignees | Email, SMS, call, push, in-app | — |
| Mindestdauer unterschritten → Aufsicht | Minimum duration not met | Supervision (property/attendance contacts); push/in-app to property assignees | Email, SMS, call, push, in-app | — |
| Einsatzabstand verletzt → Aufsicht | Visit interval violated | Supervision (property/attendance contacts); push/in-app to property assignees | Email, SMS, call, push, in-app | — |
| Manipulationsverdacht (Standort) → E-Mail | Manipulation suspicion (mock GPS / implausible travel) | Supervision with visibility of others' time tracking | — | |
| Aufgabe zugewiesen → Zuständige Person | Task assigned | Assignee | Push, in-app, email | — |
| Aufgabe fällig → Zuständige Person | Task due | Assignee | Push, in-app, email | — |
| Aufgabe fällig → Tagesbesetzung der Schicht | Task due | Today's shift staffing (additionally auto-assigns the task) | Push, in-app | — |
| Einsatz zugeteilt/geändert → Eingeteilte Person | Shift assigned/changed | Person from the event | Push, in-app | — |
| Krankmeldung eingegangen → Verantwortliche | Sick report received | First admin | Email, push, in-app | Yes |
| Krankmeldung entschieden → Mitarbeiter | Sick report decided | Person from the event | Push, in-app | Yes |
| Materialanforderung eingegangen → Verantwortliche | Material request received | First admin | Email, push, in-app | — |
| Materialanforderung entschieden → Anforderer | Material request decided | Person from the event | Push, in-app | — |
| Material nicht zurückgegeben → Mitarbeiter | Material not returned after shift end | Person from the event | Push, in-app | Yes |
| Freigabe angefordert → Verantwortliche | Review requested | First admin | In-app | Yes |
| Objektbereich verlassen | Property area left | Affected person (push, in-app); in-app to property assignees | Push, in-app | — |
| Sperrzone betreten | Restricted zone entered | Affected person (push, in-app); in-app to property assignees | Push, in-app | — |
| Verweildauer in Zone überschritten | Zone dwell time exceeded | Affected person (push, in-app); in-app to property assignees | Push, in-app | — |
Reaction default workflows
These rules sit on the umbrella triggers "… (reaction workflow)" (see above) and never fire on their own — only when a shift, a property or a reaction default explicitly selects them as the reaction. That is why they can safely ship active from the start: the assignment picker in the portal immediately offers a working rule without anything being sent unsolicited. Per area there is a simple notification variant and, in part, an escalation variant (notify supervision, wait 15 minutes, escalate to management only if there is no acknowledgement/resolution):
| Default rule | Umbrella trigger | Recipients | Channels | Active from start |
|---|---|---|---|---|
| Bei Verstoß: Aufsicht benachrichtigen | Attendance violation | Supervision (property/attendance contacts); push/in-app to property assignees | Email, SMS, call, push, in-app | Yes |
| Bei Verstoß: Eskalation ohne Quittierung | Attendance violation | Supervision → after 15 min escalation to first admin | Email, push, in-app | Yes |
| Bei Rundgang-Verstoß: Aufsicht benachrichtigen | Patrol violation | Property assignees | Email, push, in-app | Yes |
| Bei Rundgang-Verstoß: Eskalation ohne Erledigung | Patrol violation | Property assignees → after 15 min escalation to first admin | Email, push, in-app | Yes |
| Bei Aufgaben-Verstoß: Aufsicht benachrichtigen | Task violation | First admin | Email, push, in-app | Yes |
| Bei Meldung: Aufsicht benachrichtigen | Incident reaction | Property assignees | Email, push, in-app | Yes |
| Bei Meldung: Eskalation ohne Bearbeitung | Incident reaction | Property assignees → after 15 min escalation to first admin | Email, push, in-app | Yes |
| Bei Formular-Ereignis: Aufsicht benachrichtigen | Form reaction | First admin | Email, push, in-app | Yes |
| Bei Material-Ereignis: Aufsicht benachrichtigen | Material reaction | First admin | Email, push, in-app | Yes |
| Bei Service-Level-Ereignis: Aufsicht benachrichtigen | Service level reaction | First admin | Email, push, in-app | Yes |
You adjust recipients, channels, and texts in the workflow editor; default rules do not count against the package limit of active rules.
Notifications, Templates, Recipients & History
The Automation area has five menu items: Notifications (the overview with the reaction defaults), Rules (this page), Templates, Recipients & Contacts, and History. Use the menu items to reach the notification templates (message texts with placeholders — not to be confused with the template gallery for entire rules), the recipients & contacts (reachability overview), and the history: a list of all rule executions of the last 30 days with their result and — per execution — the determined recipients and deliveries per channel. Rules with permanently failed executions carry a red "N failed" badge in the overview that leads straight to the history.
Scope
By default, rules apply to the entire account. However, you can limit a rule to a single property or customer — either in the rule editor or directly in the property (property tab Automation & Notifications, where only that property's rules appear).
Good to Know
:::tip Note
- Depending on your package, the number of simultaneously active, self-created rules is limited; the overview shows your usage (e.g. "2/3"). Disabled rules and the included default rules do not count.
- The rules fully replace the former notification checkboxes in the property settings. Whatever was configured there (e.g. email on missed patrol) is now modeled as a rule.
- For new accounts, a set of more than 40 sensible default rules is created automatically — most of them ship deactivated and send nothing until you switch them on. That includes the prepared rule "Incident created → e-mail". Rules that ship active: "Missed round → email", the two sick-report rules ("Sick report received" / "Sick report decided"), "Material nicht zurückgegeben → Mitarbeiter" (material not returned), "Freigabe angefordert → Verantwortliche" (review requested) and the reaction default workflows — the latter only fire via an explicit assignment.
- Push and in-app notifications can be marked "Acknowledgement required" per rule: the entry then stays under "To acknowledge" in the inbox until it is acknowledged — for incidents, rounds, and attendance this also acknowledges the triggering event and stops the escalation. Details in the workflow editor.
- The same event triggers a rule only once — even if data from the mobile app is synchronized multiple times, you will not receive duplicate notifications.
- If a notification fails (e.g. due to a connection issue), delivery is automatically retried several times. If an execution still fails after five attempts, the administrators are informed via in-app notification; in the history it can then be restarted via the "Run again" button.
- If a rule cannot determine any recipients (e.g. an empty role), this is visibly noted in the execution result — it does not get lost silently. :::
Permissions
:::info Permission To use this page, you need the View workflows permission. Contact your administrator if you do not have access. :::
| Action | Permission |
|---|---|
| View rules | View workflows |
| Create and edit rules | Create workflows / Edit workflows |
| Delete rules | Delete workflows |
| Manage notification templates | View settings |
| See recipients & contacts | View employees or View customers |