Skip to main content
LLMs.md

Change Control

Change control puts corrections to already submitted records under approval: anyone correcting a report or an incident is filing a request. The correction only takes effect once a second authorised person approves it (four-eyes principle). Until then the original record stays untouched.

LiteLog uses the same request workflow for archiving and restoring reports, incidents and tour runs. Those two request types are always active; the approval requirement for corrections is switched on in addition.

What the workflow is for​

In regulated environments a later change to a record must not be decided by a single person alone. Change control therefore splits request and decision between two people and records both steps with reason, author and time. 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​

Both switches sit under Settings → Organization in the Change control section:

SwitchEffect
Report corrections require approvalA corrected version of a report only supersedes the original after approval.
Incident corrections require approvalChanges to incident text, category or severity are only applied after approval.

Both switches are off by default; corrections then take effect immediately as before. They apply account-wide to all properties and can be switched individually. The section is only visible to accounts with the Edit settings permission — the same permission operates the switches.

What happens when correcting​

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).

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 record Only one request can be open per record at a time. A second attempt is refused with "A request is already pending" — decide the running request first. :::

Who may approve​

Decisions are made by anyone holding the Approve archiving requests for reports and incidents permission. 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 can correct the record — the four-eyes gate is the approval, not the request.

Finding and deciding open requests​

Requests are decided on the Reports page. The "Archive requests (N)" button appears at the top right — only for accounts with the approval permission and only while something is open. It opens the list of open requests; each entry shows:

  • the type of request (Archive, Restore, Report correction, Incident correction) and the type of records,
  • the requester's reason, their name and the time,
  • for an incident correction, the requested change as an old → new preview,
  • for a report correction, the links "View original" and "View new version",
  • the affected records, expandable.

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)." Otherwise the approval would merely be a second click by the same person. 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 typeEffect of the rejection
Report correctionThe original remains the valid version. The waiting new version is cancelled; the approver's note is taken over as the cancellation reason.
Incident correctionThe incident stays unchanged; nothing is overwritten.
Archive / RestoreThe 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.

Notifications​

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

TriggerRecipientsChannels
Correction request submittedInitial adminEmail, push, in-app
Correction request decidedthe requesterPush, in-app

Recipients and channels are adjusted there. The same two rules exist for archive and restore requests.

Where the trail is​

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

EventMeaning
Correction requestedrequest filed (with reason)
Approvedrequest approved, change applied
Correction rejectedrequest rejected (with note)
Archiving requested · Archived · Archiving rejected · Restoredthe steps of the archiving workflow

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.

Good to know​

  • The switches 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 correction.
  • Requests and decisions happen in the portal. The LiteLog app has no approval screen.

Permissions​

ActionPermission
Operate the switches under OrganizationEdit settings
Request a correction or archivingedit rights on the record in question
Approve or reject a requestApprove archiving requests for reports and incidents
View the settings historyView patrol evaluation