Your data
Every warranty operation records things a standard model does not. In Fleetlane you add those fields yourself and maintain the reference data behind every dropdown, all from Settings. You don’t need a software release to do it.
Custom fields
Section titled “Custom fields”Settings › Custom Fields holds two sets of definitions: claim fields and vehicle fields. Each definition adds a field to every claim or vehicle record in your organisation.
Every custom field has a unique field key, a label, an optional description and a sort order. There are six field types:
| Type | Typical use |
|---|---|
| Text | Short references, such as a supplier batch number |
| Long text | Free-form notes |
| Number | Readings and counts |
| Boolean | Yes/no checks, such as “Customer informed” |
| Date | Calendar dates |
| Date & time | Timestamps |
Claim fields and vehicle fields have the same two further settings:
- Section groups fields under a heading on the claim or vehicle page.
- Active retires a field. A retired field disappears from forms, claim types and UI Access, but the values already recorded against it are kept.
New fields and code list changes can be tried in a test lane and promoted into production once they work.
A definition says what a field is, not who may use it. Whether a custom field is editable, required, locked or hidden is set in Settings › UI Access, by role and status, in exactly the same way as for standard fields such as repair date or mileage. A field with no rule is editable. See Access & field control.
Only users with the code list management capability can change definitions. You grant that capability to roles in Settings › UI Access.
Validation
Section titled “Validation”The server checks values every time a claim or vehicle is saved, not just the browser:
- The form rejects anything that isn’t a number in Number fields. Numbers and yes/no values are stored as their proper types.
- A new claim starts as a draft, and nothing is required yet. Once a claim is in a status where a field is required, by a UI Access rule or by the claim type, saving it with that field empty is refused.
- Field keys that don’t match a definition are rejected, and so are values for a retired field.
- A claim cannot hold a value for a field its claim type hides.
- A locked field cannot be changed by any route, including a handcrafted request.
Fields per claim type
Section titled “Fields per claim type”Not every field belongs on every claim. In Settings › Claim Types, each claim type sets every claim custom field and text category to Hidden, Optional or Required. A field with no setting for a type is Optional. The claim type can only narrow: a role rule cannot make a field editable or visible where the claim type hides it.
For example, a goodwill claim type can require a field for the approval reference, while a recall type hides that field completely.
flowchart LR F["Custom field definition<br/>type, section, active"] --> UA["UI Access<br/>editable, required, locked or hidden<br/>by role and status"] UA --> CT["Claim type<br/>hidden, optional or required"] CT --> U["What each user<br/>sees and edits"]
Where custom fields appear
Section titled “Where custom fields appear”- Claim and vehicle pages group custom fields by the section you set, in your sort order. Fields without a section appear under Other.
- Settings › UI Access lists every custom field alongside the standard fields, so each one can be editable, required, locked or hidden by role and status. The Custom fields section as a whole can also be hidden or locked. See Access & field control.
- Hidden fields are removed from what the server sends, not just hidden on screen.
Text categories
Section titled “Text categories”Settings › Text Types defines named text slots for claims and vehicles, such as “Customer statement” or “Inspection remarks”. Claim text categories have a code, name, description, icon and Active switch. Each claim type can make them Hidden, Optional or Required. Vehicle text categories can be marked as required.
Code lists
Section titled “Code lists”The Code Lists section of Settings holds the lookup tables behind dropdowns and labels. Each list has its own screen.
| Screen | What it holds |
|---|---|
| Claim Origins | Where claims come from, such as a dealer portal, email or phone |
| Claim Statuses | Claim statuses, each with a label, colour, initial-status flag and financial milestone |
| Coverage Types | What a warranty covers: parts, labour, both or extended |
| Defect Codes | What went wrong |
| Cause Codes | Root causes |
| Vehicle Statuses | Vehicle statuses, each with a label and colour |
| Material Types | Claim item categories and how their prices are set |
| Partner Functions | Business partner roles, such as claimant, vendor or payee |
Most lists have the same shape: a code, a name, a description, an Active switch and a sort order.
Statuses and the lifecycle
Section titled “Statuses and the lifecycle”The lifecycle engine decides which status a claim or vehicle is in. Fleetlane supplies the label and colour your users see for each status code. Field rules in UI Access are keyed to the same codes, so two workflows that share a status code also share its label, colour and access rules.
If a status needs attention, the Claim Statuses or Vehicle Statuses screen flags it. For example, it flags records with no status, or with more than one.