Incident reports

This page explains the term that causes the most questions in LiteLog: what exactly is an incident report — and how does it relate to reports and forms?

Reports, incidents, forms — the terms

"Reports" is the umbrella term. The Reports area contains exactly two kinds of entries:

Term	What it is	Where it originates
Report	The umbrella term. Not a data type of its own, but the name of the area and of the list.	—
Incident report	A person's message: "Something happened here." An incident, damage, an observation — usually with a photo and a short text.	Mobile app, portal ("Create report" → "Incident" template)
Completed form	A submitted answer to one of your form templates — checklist, inspection or handover protocol.	Mobile app, portal, task with mandatory form

There is no "Forms" submenu and no "Incidents" submenu. The main menu has a single entry Reports; the sidebar inside it is a filter panel (All reports · Form templates · Types · Objects). The Types filter lists every active form template — plus the Incident template. That is how you narrow the list down to incident reports only.

:::tip In short An incident report is an event someone reported. A form is a routine someone completed. Both end up in the same list because both are records of evidence. :::

The "Incident" template

Technically, the incident report is itself a form template — a special one: the system template "Incident". That is why an incident form looks the same everywhere, and why you change its fields in the same place as for any other form.

This template has four properties no other template has:

• There is exactly one per account — created automatically when the account is set up.
• It is always active. It cannot be moved back to draft and cannot be archived.
• It cannot be deleted.
• It is the fallback default template: as long as you do not mark a template of your own as the default, the incident template is preselected when creating a report.

In the list under Settings → Form templates you recognise it by the System template marker.

The default fields of an incident report

Out of the box, the "Incident" template contains five fields, in this order:

Field	Type	Required
Date	Date	yes
Time	Time	yes
Checkpoint	Checkpoint picker (checkpoints of the selected object)	no
Message	Long text	no
Photos	Photo upload	no

Date and time are required on purpose: together they form the incident timestamp that LiteLog uses to detect duplicate submissions. Message and photos are optional on purpose — an incident report may consist of a photo alone or a note alone. An entry with an image but no text appears in the list as a photo report.

In addition, without anyone typing anything:

• Object — comes from the page context or from the object selected in the app, and is required for an incident report.
• Person, device and timestamp — set automatically by the server.
• GPS location — if the device provides it. If you enable the location lock on the object, the phone must be inside the object area while capturing (see Incidents (object)).

Changing, removing or requiring fields

There is no separate switch in the settings for this. You edit the template — exactly like any other form:

1. Open Settings (group Capture & Forms).
2. Choose Form templates.
3. Click the Incident template in the list — the form editor opens as a full page.
4. Click a field and adjust it on the right: change the label, switch Required on or off, remove the field via the bin icon.
5. Save & publish.

This is how you hide the checkpoint if you work without checkpoints, or make the message mandatory so nobody sends a photo without an explanation.

:::info What is different in this template

• Only six field types are allowed: section, long text, photo, date, time and checkpoint. An incident report is written into dedicated data columns, not into a free-form answer table — so not every field type fits. If you insert another type, LiteLog rejects the save.
• The five default fields are the only possible answer fields. You can remove them and add them back, but you cannot invent a sixth, freely named question. For your own questions, create your own form template — that one supports every field type.
• Incident reports already captured stay as they were. On save, LiteLog increments the template version; older reports keep the fields they were submitted with. :::

Category and severity

Neither category nor severity is asked for during capture — that would slow down the person on site. Both values are assigned afterwards, in two ways:

• Manually — in the incident detail view you pick Category and Severity. The report is then marked Manual.
• By AI classification — provided you have enabled it (see below).

Severity has four levels: Low · Medium · High · Critical. It appears as a coloured marker in the list, can be filtered, and can be used as a condition in automation rules. Categories are maintained under Settings → Incident categories.

AI classification — off by default

Automatic classification is not active out of the box. It is a deliberate double opt-in — both switches have to be on:

1. Account-wide: Settings → Integrations → "AI features" card → "Auto-classify incidents" switch
2. Per object: the "AI classification of new incidents" switch on the object's Incidents tab — it is locked while the account switch is off, and off by default for every object.

While the switches are off, the feature stays completely silent — nothing is analysed and nothing is suggested. Instead, the detail view of an unclassified incident shows a hint with an Enable button that leads to the settings.

Once both switches are on:

• Every new incident report is classified in the background, typically within a few minutes.
• The AI supplies a category, a severity and a suggested title.
• If it is unsure, the orange marker "Low confidence — please review" appears; uncertain categories are left empty rather than guessed.
• A manually set value always wins and is never overwritten by the AI.
• "Re-run AI" restarts classification for a single report.

:::caution Only from the moment you switch it on Existing incident reports are not classified retroactively. Classification applies from the moment you enable it, only to newly arriving reports — and only for objects whose AI switch is on. Older reports can be caught up individually via "Re-run AI". :::

All details — display, voice-memo transcription, budget — are documented under AI features.

AI text version of an incident

Besides the classification, the AI can also polish the incident text itself. It rewrites the raw report into a factual, fully formulated version — this is a separate feature with its own switch, and it is off by default.

What the AI does with the text

The version is more than a translation. Even a report already written in your language is rewritten: colloquial language, typos, abbreviations and clipped keywords become a factual, neutral report-style text of one to three sentences. "broken glass in the yard by the bins, quite a lot" becomes, for example, "There is a large amount of broken glass in the yard in the area of the bin store."

Further:

• Reports in other languages are brought into your account's language. A report captured in Turkish, Russian or Polish is therefore readable for you.
• If only a photo and no text is available, the AI writes a descriptive report from the image. If nothing relevant is recognisable, or the photo is unusable (blurred, too dark, too close), no version is created — the AI does not guess.
• Nothing is invented. Times, names, room and floor references, quantities, measurements, costs, causes, attributions of blame and repair recommendations that are neither in the text nor clearly visible in the photo must not appear.
• People are referred to neutrally as "a person" or "several people" only — without names, appearance, clothing, gender, age, origin and without vehicle registration numbers.

A human has to approve the version

A generated version is initially only a suggestion. Only human approval turns it into the customer-facing text: from then on it replaces the raw text in the customer PDF, in the CSV export and in the incident e-mail.

:::caution Nothing changes without approval — and nothing backs up While nobody has decided, the raw text goes out as before. There is no blocking effect: no sending waits for the approval, no export is blocked, no automation stops. The approval is an improvement, not a gate.

The original is never lost. It stays stored unchanged and can always be viewed in the incident detail — before approval, after approval, and also when the version was edited by hand before approval. :::

Approve, discard or edit first — in the portal

Open the incident in the Reports area in the detail view. The message card there now has a switch with up to three views:

View	What it shows
AI version	The polished version. It is preselected as soon as a version exists.
Translated	The machine translation of the original, if the report was captured in another language.
Original	The unchanged raw text, exactly as it was captured.

Above the version you see where it came from — "Generated from the incident text", "Generated from the photo" or "Generated from incident text and photo" — and next to it the state ("Approval pending" or "Approved on … by …"). "Show original" places the raw text underneath for comparison without leaving the view.

In the header of the detail view there are three actions, as long as no decision has been made:

1. Approve — the version is adopted and appears in the customer report from now on.
2. Ignore — the version is not used; the customer report keeps the incident text. LiteLog asks for an optional reason.
3. Edit — the version becomes editable in the text field, with the original permanently shown beside it. "Save and approve" adopts your own wording, "Cancel" discards the change. While you are editing, paging to the next incident is disabled so the draft cannot be lost.

The decision applies to the version as a whole and is made only once: a version that has already been approved or ignored cannot be reversed afterwards. Who decided and when is shown on the incident afterwards; an edited version is additionally labelled "edited".

Approve, discard or edit first — in the LiteLog app

The same works on the go. Open the incident via More → Analysis → Reports; the message card in the incident detail carries the version. Two pills switch between AI version and Original text; below them are Approve, Discard and Edit. Long versions are unfolded via "Show more".

:::info Approving needs a connection The decision is online-only in the LiteLog app. Without a connection you still see the version, but the buttons are greyed out. That is deliberate: an approval queued offline could later approve a version that has been regenerated in the meantime and that nobody has read. :::

The states of an incident

State	What you see	What to do
Being generated	"AI version is being generated …"	Nothing. Generation runs in the background, usually within a few minutes.
Awaiting approval	The version with the marker "Approval pending"	Read the version and approve, discard or edit it first.
Approved	"Approved on … by …", possibly with the addition "edited"	Nothing. The version now appears in the customer report.
Ignored / discarded	"Ignored on … by …" (app: "Discarded")	Nothing. The customer report keeps the raw text.
Generated from the photo only	The version with the note "Generated from the photo"	Check the version against the photos particularly carefully before approving.
No version possible	"AI version could not be generated."	Nothing further — the raw text stays. The usual cause is too little content, or a version that failed LiteLog's plausibility checks.
AI budget used up	"AI budget used up" with the note about the turn of the month	Either wait for the turn of the month or book more budget under AI features.
AI off at the property	No version and no note at all	Switch on AI classification at the property, see Incidents (object). Reports that already arrived are not polished retroactively.

Labelling in the customer PDF

When an approved version is printed into a customer PDF, a labelling footnote appears below the incident table: "This report was edited by AI and approved on … The original is available in the LiteLog portal." If a report contains several labelled incidents, the footnote names the most recent approval date. Without an approved version, the footnote does not appear.

Prerequisites

Text polishing depends on three conditions — all three must be met:

1. The account-wide switch "Auto-classify incidents" is on.
2. The account-wide switch "Polish incident texts" is on (it cannot be enabled without the first). Both are found under Settings → Integrations → AI features.
3. The AI classification switch is on at the property. There is deliberately no second property checkbox — classification and text version are produced in the same step.

:::caution Not to be confused with: approving a form report LiteLog has two things called "approval", and they have nothing to do with each other:

• Approval before customer sending decides whether a submitted form report may go to the customer at all. It is switched on at the form template and has a blocking effect: no approval, no sending. Described under Approval & Customer Sending.
• Approval of the AI text version — this one — only decides which text is output in an incident: the polished version or the raw text. It has no blocking effect; without a decision the raw text goes out. :::

Escalation does not happen by itself

A common misconception: "critical incidents get escalated automatically." LiteLog does not do that out of the box. Without your input, an incident is captured, classified (if the AI is on) and placed in the list — nothing more. Who gets notified, and what happens when nobody reacts, is an automation rule that you have to activate.

Two triggers are available:

Trigger	Fires
Incident created	immediately when the report arrives
Incident classified	only once category and severity are known — the right trigger if you want to condition on "severity = high"

After the first notification, the escalation itself is a chain of four cards: delay (e.g. wait 30 minutes) → state probe (has anyone reacted meanwhile?) → condition (only continue if nobody acknowledged) → action (notify management). The building blocks are described in the workflow editor.

A faster route is the template gallery on the Rules page. It holds ready-made chains you only need to adopt:

Template	What it does
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.
Incident → AI triage → task	Classifies and, on high urgency, automatically creates a high-priority task.
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.

Both routes are one-off setup steps — after that the chain runs for every incident report.

:::caution Pre-installed rules are switched off New accounts come with a prepared rule "Incident created → e-mail". It ships deactivated and sends nothing until you switch it on — either via the toggle in the rule table or via Activate on the matching gallery card. Choose the trigger deliberately: "Incident created" reacts immediately but does not know the severity yet. :::

Where incident reports can come from

• Mobile app — the main route. See Create an incident report; works offline too.
• Portal — Create report with the "Incident" template.
• Ticket-QR poster — customers or passers-by scan the QR code at the object and report an issue without an app and without signing in, see Ticket QR.
• Automation — the action Open incident creates an incident report itself, e.g. for a missed checkpoint or an unmet attendance requirement.
• Public REST API — POST /v1/incidents with the incidents:write scope, see API.

Incident capture can be switched on and off per object: Incidents (object).

Good to know

:::tip Note

• Incident reports created during a patrol also appear in the timeline of the patrol protocol.
• Submitted incident reports cannot be changed afterwards. Only the downstream classifications (category, severity, title) and the AI text version before its approval remain editable — the captured original text itself is never touched.
• If the reporting person is deleted later, the report remains (only the person reference is dropped). Deleting the object deletes its incident reports with it.
• If you need fixed extra fields for a recurring case ("cash drop in the safe"), build your own form template for it instead of overloading the "Incident" template. :::

Permissions

:::info Permission You need View incidents to see incident reports and Create incidents to capture them. The AI text version is approved, discarded or edited by whoever holds Edit incidents — in the portal as well as in the LiteLog app. Editing the "Incident" template requires Edit forms; the account-wide AI switch requires Edit settings. Contact your administrator if you do not have access. :::

Action	Permission
See incident reports in the list	View incidents
Capture an incident report	Create incidents
Set category / severity, "Re-run AI"	Edit incidents
Approve, ignore or edit the AI text version	Edit incidents
Change the fields of the "Incident" template	Edit forms
Turn AI classification and text polishing on/off account-wide	Edit settings
Create an escalation rule	Create/edit workflows

Related pages

• Reports
• Create report
• Form templates
• AI features
• Incident categories
• Automation — Rules
• Incidents (object)
• Approval & Customer Sending (form reports)
• Incident details (app)