How lifecycles work

Every claim and vehicle in Fleetlane moves through a lifecycle of statuses. Fleetlane does not hard-code those lifecycles; they are run by the lifecycle engine, a separate engine that Fleetlane runs on. The engine is also how you extend Fleetlane with your own rules, logic and systems.

Policies decide every status change

Each lifecycle is governed by a policy. A policy defines:

• the statuses a claim or vehicle can be in
• the steps that can be started from each status
• which status each possible result of a step leads to

A status can only change the way the policy allows. If the policy defines no route from the current status for a given result, the record does not move. Fleetlane never invents a transition the policy did not authorise.

Whether a user may start the steps available in a given status is governed by role configuration in Fleetlane, so the same policy can offer a step to head office and not to dealers.

Actions: the units of work

The work inside a lifecycle is done by actions. There are four kinds:

Action	What it does	Typical use
Check	Evaluates business rules against the record’s data	Is the claim inside the warranty period? Is the amount under the approval threshold?
Call	Calls an external system over HTTP	Look up a part price, notify a dealer management system, create a document elsewhere
Code	Runs custom logic you write in JavaScript	Calculate a contribution split, reshape data between systems
OData	Reads from or writes to an OData service	Create or update records in systems such as SAP or Microsoft Dynamics

Custom logic runs in an isolated sandbox with no network, file or process access, under time and memory limits. Reaching another system is done through a Call or OData action, whose credentials are stored encrypted.

Sequences chain actions together

Actions are combined into sequences that run in order. Each action can use the sequence’s inputs and the outputs of earlier actions, so one sequence can fetch data, check it, transform it and send it on.

A sequence finishes with a result: success, a named exit condition such as rejected or manual_review, or a technical failure. Each result carries a severity (info, warning, error or critical). Sequences do not decide what happens next; the policy does.

The result decides the next status

For each status, the policy maps every result of a sequence to a next status, with an optional default outcome and a separate status for technical failures, so a system outage is not mistaken for a business decision.

Because meaning lives in the policy, one sequence can serve several policies: the same validation can reject a claim under one claim type and send it for manual review under another.

sequenceDiagram
  actor U as User
  participant V as Fleetlane
  participant E as Lifecycle engine
  participant X as Your systems
  U->>V: Start a step on a claim
  V->>V: Check the role may run it in this status
  V->>E: Start the sequence
  E-->>V: Record locked
  loop Each action in the sequence
    opt Call or OData action
      E->>X: Request
      X-->>E: Response
    end
    E->>E: Append to the lifecycle log
  end
  E->>E: Policy maps the result to the next status
  E-->>V: Status transition
  V->>V: Apply status, store a claim version
  E-->>V: Record unlocked

Draft, publish and version pinning

Actions, sequences and policies are all created as drafts. Drafts can be edited and tested freely.

When a draft is ready, it is published. Once published:

• it can no longer be edited or deleted; this is enforced by the database, not only by the application
• the steps inside it are frozen as well
• who published it, and when, is recorded
• any further change is made as a new version

References are pinned to exact versions: a sequence uses specific action versions, a policy uses specific sequence versions, and each record type is bound to a specific policy version. A new action version never silently changes a policy in use, and records can only be moved onto a published policy.

flowchart LR
  RT["Claims"] --> P["Policy v3"]
  P --> S1["Sequence: validate v2"]
  P --> S2["Sequence: pay v5"]
  S1 --> A1["Check: warranty period v4"]
  S1 --> A2["Call: price lookup v1"]
  S2 --> A3["OData: post to finance v2"]

The versions above are illustrative.

One run at a time

While a sequence runs for a claim or vehicle, the record is locked. A second sequence cannot start on it, and Fleetlane refuses edits to a claim being processed, recording each refused edit in the action log. When the sequence finishes, Fleetlane applies the resulting status and the lock is released.

Everything is recorded

Every action execution is written to the lifecycle log, including:

• the action and the exact version that ran
• the sequence and run it belonged to
• the input it received and the result it produced
• the exit condition, its severity, and the outcome rule that was applied
• when it ran and how long it took

The lifecycle log is append-only: entries cannot be updated or deleted, and retries and failures stay visible beside successes. For any past decision you can establish what ran, what it saw, and which policy version was in force. In Fleetlane, the Activity section of each claim and vehicle lists the lifecycle steps that ran on it, who started them and their outcome.

See Audit & history for how this fits with the rest of Fleetlane’s record keeping.

Extending Fleetlane with your own logic

Customer-specific behaviour lives in lifecycle policies rather than product code:

• Your rules become Check actions.
• Your calculations become Code actions.
• Your systems are reached through Call and OData actions, at the point in the lifecycle where they belong.
• Your process is the policy: which steps are offered in which status, and where each result leads.

The lifecycle engine has lanes of its own. Each Fleetlane lane is paired with one engine lane: production with production, a test lane with a test lane, so lifecycle runs for test claims happen apart from production. See Lanes.

Changing any of these means publishing a new version, not waiting for a Fleetlane release. The previous version stays on record with every decision made under it.