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 opt-in and is switched on here:

Settings → Integrations → "AI features" card → "Classify incidents automatically" switch

While the switch is 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 Activate button that leads to the settings.

Once the switch is on:

• Every new incident report is classified in the background, typically in under a minute.
• 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, and only to newly arriving reports. Older reports can be caught up individually via "Re-run AI". :::

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

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.
• 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) remain editable.
• 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. Editing the "Incident" template requires Edit forms; setting the AI switches 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	View incidents
Change the fields of the "Incident" template	Edit forms
Turn AI classification on/off	Edit settings
Create an escalation rule	Create/edit automation

Related pages

• Reports
• Create report
• Form templates
• AI features
• Incident categories
• Automation — Rules
• Incidents (object)