Change Control

Change control puts changes under approval: anyone making a change is filing a request. The change only takes effect once a second authorised person approves it (four-eyes principle).

The workflow covers two areas:

Area	What it includes
Records	Corrections to already submitted reports and incidents, plus archiving and restoring reports, incidents and tour runs.
Configuration	Changes to form templates, to the rhythm of a task, to roles and permissions, to evidence-relevant property settings, to patrol configurations and to time tracking settings.

You switch on each area individually — archiving included. When an area is off, the action takes effect immediately.

What the workflow is for

In regulated environments a later change to a record must not be decided by a single person alone. The same applies to the settings that govern how things are captured: rewriting a form template changes the content of every future report, and granting permissions changes who is allowed to decide at all. Change control therefore splits request and decision between two people and records both steps with reason, author and time.

For records the original is never overwritten: an approved report correction creates a new version and marks the original as Superseded, while an approved incident correction writes the old and new value into the incident history.

Switching it on

The switches sit under Settings → Policies (group Compliance & approvals) in the Change approval section. First, three switches for records:

Switch	Effect
Report corrections require approval	A corrected version of a report only supersedes the original after approval.
Incident corrections require approval	Changes to incident text, category or severity are only applied after approval.
Archiving and restoring require approval	Reports, incidents and tour runs are only archived or restored after approval. With the switch off, one click archives immediately — with an optional reason and the same trail in the history (Archived / Restored), just without a request.

Below them, a table for configuration — one row per area, with the columns Requires approval and Signature required:

Configuration	What becomes a request
Form template	Changing a template, publishing it or switching its status (draft, active, archived) — including via the multi-select of the template list and via the API.
Task rhythm	Saving the recurrence plan of an existing task.
Roles and permissions	Creating, changing or deleting a role.
Property settings	Only the settings of a property that determine how a record of evidence comes about: location check (GPS zone, beacon threshold, allowed check-in methods, photo fallback on scan, AI classification of incidents), the signature requirement and its allowed methods, the geometry of the property on the map, and switching the areas time tracking, patrols and incidents on or off. Name, address, notes, time zone, responsible persons and the visibility tiles (documents, chat, material, status) remain everyday work and run without a request; they still appear with old and new value in the settings audit trail.
Patrol configuration	Creating, changing, deactivating or deleting a patrol.
Time tracking settings	Saving the time tracking settings of a property.

Below the record switches there is one more switch: Change reason required for every settings change (portal, app, API, MCP). It puts no area under approval; it enforces a reason consisting of code and text for every change to a setting. Without a reason, LiteLog does not accept the change on any surface. Which actions need a reason and which do not is shown in the table When a reason is mandatory. Switch it on only once all devices run an app version with the reason dialog; older app versions would only see an error message.

All switches are off by default. LiteLog puts nothing under approval on its own — you decide per account and per area what takes part. With an area switched off, LiteLog behaves there exactly as before: the change is written immediately.

The Signature required column additionally demands a digital signature on the decision. It can only be operated once the area requires approval — without a decision there would be nothing to sign.

The section is only visible to accounts with the Edit settings permission; the same permission operates the switches.

What happens when correcting a record

Correcting a report

A submitted report is not edited but replaced by a corrected version: in the report detail view, open the ⋯ menu and choose "Create corrected version". The editor opens a new response based on the original and requires a reason (at least 5 characters). Procedure, rules and sending of the new version — independent of the switch — are described under Correcting a report afterwards.

With the switch on, submitting does the following:

• The new version is saved, the original keeps its state — it is not yet marked as "Superseded".
• A request of the type Report correction is created.
• While your request is open, the report carries the Correction requested marker for you.
• Only the approval marks the original as Superseded and makes the new version the valid one.

Correcting an incident

In the incident detail view, "Correct incident" lets you change the incident text, the category and the severity. A reason is mandatory (5 to 2000 characters). Only the fields actually changed are sent; without a change no request is created.

With the switch on, LiteLog confirms with "Correction submitted — it will only take effect after approval." The incident stays unchanged until approval. Re-classifying an incident that a person has already classified is equally subject to approval; the first human classification of an incident remains a direct path.

:::info One open request per entry Only one request can be open at a time, per record and per setting. A second attempt is refused with "A request is already pending" — decide the running request first. :::

What happens when changing a setting

The difference from the record case matters: the change is not saved. It is not hidden, not parked as a draft and not held as a second version — it is never written in the first place. Until approval the database holds only the old, reviewed state; the new one exists only inside the request.

That is why nothing unreviewed can reach a device. The LiteLog app fetches templates and property data in full on every sync and replaces its local set with them. If an unreviewed version were sitting in the database, it would have reached every device on the next sync. Because it is not there, that cannot happen.

In detail:

• The reason is mandatory. Without it LiteLog does not accept the change, and no request is created either — the reason is the only thing that tells the approver about the intent; the old→new comparison only shows the what. Where the editor knows about the approval requirement, it asks for the reason in a dialog before submitting.
• Creating needs no reason (initial creation). Creating, completing, submitting and reporting are the recording itself. Whoever creates a control point, an area, an account, a task (also from an incident or a report), a form template (also from the catalogue), an automation rule, a category or a status definition is not asked for a reason — not even when the tenant has switched on the reason requirement for settings changes under Policies. This holds on every surface alike: portal, app, Public API and AI connection. Every later change, every cancellation, every archiving and every change to the configuration still needs the reason. In the settings history and in the export, such creation rows show the text Initial creation in the Reason column; a reason given voluntarily is stored and shown. Exception: creating under change approval (roles, patrol route plans) remains a request and needs the reason.
• The editor is locked until the decision. While a request for the same setting is open, the notice "Change awaiting approval" appears with the requester's name and a link to the request; saving is not possible.
• Automatic saving is suspended. Where LiteLog otherwise saves in the background, under approval it deliberately only files a request on an explicit click — otherwise every keystroke would create its own request.
• The approval replays the change under the requester's identity. The history therefore shows who wanted the change and, separately, who approved it. Every check that would have applied to the direct change also applies on replay: a request is not a way around them.

Roles and permissions: the rule that comes along

As soon as any area of change approval is switched on, anyone changing a role that holds the approval permission needs an approval — even if the switch for roles itself is off. This applies to all three operations: changing the role, deleting it, and granting the approval permission through the change in the first place.

Without this rule the whole workflow would be pointless: an administrator could grant themselves the approval permission and then approve their own requests — or take the permission away from the only approver, leaving nobody able to decide. In the policy table under Settings → Policies that row therefore carries a note; with another area on and the roles switch off it shows Partly enforced. The switch still governs all other roles.

With all switches off this rule does not apply either: there is no procedure left to protect, and roles are written immediately like any other setting. A tenant with a single administrator can thus maintain roles without a second account having to approve.

When the baseline has moved

Hours can pass between request and approval. LiteLog therefore records the reviewed starting state with the request and compares it again before applying it.

If someone has changed the same setting in the meantime — through the portal or through the API — the request no longer matches what is there today. LiteLog then does not apply it but rejects it. The request appears in the list as rejected and carries the note CONFIG_BASE_CHANGED.

This is intended. The alternative would be to apply a change on top of a state nobody reviewed: the approver would have seen a comparison that no longer holds, and the result would be a mixture of two intentions. Anyone seeing such a rejection looks at the current state and files the request again.

If the area of a request cannot be resolved at all any more — because it was removed from LiteLog, for instance — the request is likewise rejected, with the note CONFIG_TYPE_UNKNOWN. Here too: closed, rather than silently booked as approved.

Who may approve

Decisions are made by anyone holding the Approve archiving requests for reports and incidents permission. It covers every request type, configuration requests included. It is deliberately narrowly distributed: when existing accounts were upgraded, roles holding the Edit properties permission received it (management roles), and admin roles hold it anyway. Anyone else who needs it is granted it under Settings → Hierarchy & Roles.

Requesting, by contrast, is open to anyone who would be allowed to make the change without the approval requirement — the four-eyes gate is the approval, not the request.

Finding and deciding open requests

Requests are decided in two places, depending on what they concern:

Requests about	Where they are decided
Reports, incidents, tour runs	Reports page, "Archive requests (N)" button at the top right
Settings (form template, task rhythm, roles and permissions)	Settings → Change approvals

Both lead into the same decision view; there is only one way to decide a request.

The Change approvals menu entry sits in the Compliance & approvals group, directly below Policies, where the switches live. It only appears for accounts with the approval permission — not for everyone who may view settings. The page lists the requests about settings and can be filtered by status (open, approved, rejected), by area and by period. It deliberately also shows decided requests: who approved or rejected what, when and with which reason would otherwise be nowhere to be seen.

Each entry shows:

• the type of request and the area concerned,
• the requester's reason, their name and the time,
• the requested change as an old → new comparison,
• for a report correction, the links "View original" and "View new version",
• for decided requests, who decided and their note.

Approve applies the change. Reject requires a note (mandatory field, up to 500 characters).

Why you cannot approve your own request

A request you filed yourself does appear in the list, but you cannot decide it: LiteLog refuses the attempt with "You must not approve your own requests (four-eyes principle)."

This block does not depend on how permissions are cut; it is checked on the server with every decision. It therefore cannot be bypassed by a more generous role. So a second account with the approval permission has to exist — plan for that when switching the feature on.

If two approvers decide at the same time, only the first decision takes effect; the second reports "This request has already been decided."

What a rejection does

Request type	Effect of the rejection
Report correction	The original remains the valid version. The waiting new version is cancelled; the approver's note is taken over as the cancellation reason.
Incident correction	The incident stays unchanged; nothing is overwritten.
Change to a setting	The setting stays as it was. Nothing was ever written, so there is nothing to roll back; the editor is free again afterwards.
Archive / Restore	The records stay untouched.

The requester sees the approver's note. A rejected request is closed — for another attempt, file a new request.

Signature on approval

If an affected property requires a digital signature for reports or incidents, the decision requires a signature too: LiteLog asks for the password again before completing it and stores a signature manifest for the decision. If a request covers several properties and one of them requires the signature, it applies to the whole request — the approval is one action and cannot be partly signed.

For settings there is no property the signature requirement could hang on. It comes from the Signature required column of the policy table instead, that is, per area. In both cases the digital signature has to be booked for your account.

Notifications

Two shipped rules under Automation rules carry requests to the people involved:

Trigger	Recipients	Channels
Correction request submitted	Initial admin	Email, push, in-app
Correction request decided	the requester	Push, in-app

Recipients and channels are adjusted there. The same rules apply to requests about settings; archive and restore requests have two rules of their own.

Where the trail is

Every step writes a line into the change log — visible under Activity log, section Settings (settings history), filterable by Area:

Event	Meaning
Correction requested	request filed (with reason)
Approved	request approved, change applied
Correction rejected	request rejected (with note)
Archiving requested · Archived · Archiving rejected · Restored	the steps of the archiving workflow

Requests about settings appear in the same log under the area the setting belongs to: a template change under Form template, a role change under Role, a task rhythm under Property (the rhythm hangs off the property through the task).

In addition, the approved change appears in the history of the record itself — for an incident as an old→new line with reason and author, for a report as the Superseded marker on the original with a link to the new version.

Exporting requests

The export icon (download) in the header of Settings → Change approvals downloads the requests as CSV or Excel — evidence for audits and inspectors of every request and its decision. The export runs in the background, appears under Export & Delivery as Change requests, and can be scheduled there as a recurring delivery.

• Scope: every request type in one file — configuration changes as well as the archiving, restore and report/incident correction requests of the Reports page. Without a status filter the file contains open and decided requests. Approvers see all requests of the company, everyone else only their own.
• Filters: the page's status, area and period (time of request).
• Columns: Requested at (local / UTC) · Requested by · Username · Type · Area · Subject · Property · Reason · Change (Field: old → new) · Status (Open / Approved / Rejected) · Decided by · Username (approver) · Decided at (local / UTC) · Decision note · Signature status · Signature meaning · Checksum (SHA-256) · Manifest ID · Request ID · Batch ID.
• Frozen names: requester and approver appear as they were named at the time of the request or decision — renaming the account later does not change the evidence. For requests from before this recording started, the current name is shown with the suffix (current).
• Decision note: if the system closed a request itself (for instance because the baseline moved in the meantime), the reason is given in plain words, starting with Rejected automatically.
• Signature: No signature means the decision did not require a signature; otherwise the verification status of the signature manifest is shown (Signed, Signature rejected, Signature missing) with meaning, checksum and manifest ID — the same values as in the signature log.
• Permission: Export round evaluation. At most 50,000 rows per file — above that, narrow the period, status or area.

What the workflow does not cover

Change control secures changes to what already exists. It explicitly does not cover:

• Templates LiteLog creates itself. When an account is created and when the industry is set or switched, LiteLog creates the matching standard templates. They come into being without a request.
• New templates and the catalogue import. Creating a template or adopting one from the template catalogue is a new entry and runs without approval. The same goes for marking a template as the default and for re-translating it.
• The bill-of-quantities import. It writes positions, form templates and tasks including their rhythm in one go, entirely without a request.
• All other settings. Only the six areas named above can be put under approval. Everything else — everyday fields of the property, catalogues, automation rules, accounts — continues to take effect immediately. With the mandatory reason switched on, each of these changes still needs a reason.

This boundary is drawn deliberately: a new entry has no reviewed prior state a change could be compared against. For the quality system that means the initial setup of an account and every import have to be treated as their own documented setup action — they appear in the settings history, but not as a request.

The organisational boundary

An account with full administration rights can create a second role with the approval permission and staff a second account with it — obtaining the second pair of eyes for itself. Technically this is no silent bypass: creating a role with the approval permission is itself subject to approval, and every role change appears in the settings history. At the end, however, there is still one person holding both accounts.

No technology helps against this, only organisation. Running the four-eyes principle credibly requires:

• a named, person-level assignment of the approver role,
• a separation between whoever changes settings and whoever approves,
• a regular review of who holds the approval permission — the settings history shows every grant.

LiteLog supplies the evidence; the responsibility structure behind it remains a matter for your quality system.

Good to know

• The switches for records only affect corrections. Capturing new reports and incidents is unaffected.
• An archived record can no longer be corrected; request its restoration first.
• Change control is independent of the "Approval before sending to customer" setting on form templates — that one governs sending, not a change.
• Access through the API also runs through the workflow for form templates. A key is not a way around it.
• Requests and decisions happen in the portal. The LiteLog app has no approval screen.

Permissions

Action	Permission
Operate the switches under Policies	Edit settings
Request a correction or archiving	edit rights on the record in question
Request a change to a setting	edit rights for that setting
Approve or reject a request	Approve archiving requests for reports and incidents
Open the Change approvals page	Approve archiving requests for reports and incidents
Export requests	Export round evaluation (approvers: all requests, otherwise only your own)
View the settings history	View patrol evaluation

Related pages

• Audit Trail Principles — the reason matrix and the fourteen principles
• Evidence package: exports for auditors
• Data Integrity & ALCOA+
• Digital Signature
• Security & Privacy
• Activity log
• Reports
• Settings — menu group Compliance & approvals with Policies and Change approvals
• Hierarchy & Roles
• Managing tours — archiving tour runs through the same workflow