Audit & history

Fleetlane keeps several complementary records: versions of the business records themselves, a log of what people and systems did to them, a log of traffic with your other systems, and the lifecycle log of every automated decision. Together they let you answer what a record looked like, who changed it, and why it moved.

Version history on claims and vehicles

Every time a claim’s lifecycle status changes, Fleetlane stores a complete snapshot of the claim as a new numbered version. Each snapshot contains:

• the claim header as it stood after the change
• its items and their totals
• the business partners on the claim
• the status it moved into, including any financial milestone that status represents
• the lifecycle step and run that caused the change, and who started it

Vehicles work the same way. Each change in a vehicle’s lifecycle status produces a new numbered snapshot of the vehicle.

These snapshots are written by the database itself as part of the status change. The application cannot change a status without the snapshot being taken.

Versions of allocations and distributions

Budget allocations and their distribution to dealers are kept as numbered versions rather than edited in place. A new version starts as a draft and can be based on a previous version. Dealer distributions are finalised once agreed. Earlier versions remain available, together with who created each one.

Action log

Fleetlane records the actions taken on claims, vehicles and campaigns in an action log. Each entry states:

Field	Meaning
Action	What was done, with a readable summary
Source	A user, Fleetlane itself, or the lifecycle engine
Actor	The user responsible, where there is one
Result	Succeeded, denied, failed or ignored
Time	When it happened

Refused attempts are recorded as well as successful ones. For example, an attempt to edit a claim while its lifecycle is running is logged as denied.

Integration traffic log

Traffic between Fleetlane and your other systems is recorded in an integration traffic log. It covers inbound and outbound traffic, including API key authentication, webhooks, calls to external systems and event delivery. Each entry records:

• the direction and the kind of traffic
• the system, event and record concerned
• whether it succeeded, failed or was rejected, with the response code
• how long it took
• a preview of the payload and response

Administrators can review this log in Settings, under Integrations. It is usually the first place to look when a partner system reports that something did not arrive.

Lifecycle log: append-only

Every step the lifecycle engine runs is written to the lifecycle log. See How lifecycles work. Each entry records the action and its exact version, the input and result, the exit condition and severity, the outcome rule applied, and timing.

The lifecycle log is append-only, and this is enforced inside the database. Database triggers reject ordinary update and delete attempts. Privileged database administration and retention procedures remain separate operational concerns. Retries and failures are kept alongside successful runs, so the record shows what actually happened, not a tidied summary.

Published policies cannot be changed

Lifecycle policies, the sequences they run and the actions inside them all move from draft to published. Once published, they are fixed, and this is also enforced by database triggers:

• a published policy, sequence or action cannot be modified or deleted
• the steps of a published sequence, and the status-to-sequence mapping of a published policy, cannot be modified or deleted
• publishing is refused unless it records who published and when

Changes are made by publishing a new version. Because every lifecycle log entry refers to the exact versions that ran, you can always tell which rules were in force when a decision was made, even after those rules have since changed.

flowchart LR
  SC["A claim changes status"] --> V["Claim version<br/>snapshot of the claim"]
  SC --> AL["Action log<br/>who did what, including refusals"]
  SC --> LL["Lifecycle log<br/>append-only, exact versions"]
  SC --> EV["Events to your systems"]
  EV --> TL["Integration traffic log"]
  LL --> PP["Published policy versions<br/>cannot change"]

Question	Where the answer is
What did this claim look like at each stage?	Claim version history
Who changed it, and was anything refused?	Action log
Did our system receive the update?	Integration traffic log
Why did it move to this status?	Lifecycle log
Which rules applied at the time?	Published policy versions