Audit log
Changes made on portal pages and through the platform's API are written to the audit log: what happened, to which record, who did it, when, and the values before and after. You read a record's history from its Audit logs action, within the same limits that decide which records you can see.
Overview#
The audit log is a permanent, append-only history of changes. Creates, updates and deletes made on portal pages and through the platform's API are recorded. Records created or updated by a bulk import and every step of a settlement batch are recorded too. Entries are never edited or deleted, not even by the platform team. The Recent activity card on a detail page is built from the same entries — see Check who changed a record and when.
What an entry holds#
| Field | What it shows |
|---|---|
| Timestamp | When the change was saved |
| Action | One of the actions below |
| Actor | The person who made the change, with the IP address they used. Empty for changes the platform makes itself |
| Object | The record's name as it read at the time of the change |
| Changes | For an update, each changed field with its old and new value; for a create, the record's values as created |
Actions#
| Action (as shown) | Recorded when |
|---|---|
| Created | A record is created |
| Updated | A record's fields change |
| Deleted | A record is deleted. Deleted records are kept, so the history survives |
| Activated / Inactivated | A record is switched active or inactive on a portal page. This is its own entry; any other fields changed in the same save get a separate Updated entry |
| Logged in / Logged out | A user signs in or signs out of the portal, a driver signs in to the Driver App, or a store device is activated. These entries belong to user accounts and store devices, so only the platform team reads them |
| Failure | A settlement batch step fails. Only the platform team reads these |
| Other | A system or integration event on the record, such as a fuel-partner order update, or the platform team previewing a page as another role |
What is recorded#
- Portal changes. Every create, update and delete made on a portal page or through the platform's API, with field-level before and after values.
- Role changes. When a user is created, or their role changes, the entry also shows the role before and after (empty when there was none). Changing only the role still writes an Updated entry. The role's permission list is not copied into the log.
- Passwords and profile pictures. A password changed on the change-password page, or set by an administrator, is recorded as an update that notes the password changed. A new profile picture is recorded as an update.
- Sign-ins. Only successful sign-ins are recorded. A session that simply expires records no sign-out.
- Bulk imports. One entry per record an import creates or updates — vehicles, stores, drivers and staff — not just one entry for the import. The actor is the user who started the import; the import job's number is stored with each entry but not shown on the Audit logs page. Updates show real before and after values. A staff row that changes an existing user's role or store assignment is recorded as an update. An import that fails and rolls back writes no entries. For the import tool itself, see Bulk import from spreadsheets.
- Settlement batches. Every step of a settlement batch — transfer started, funds received, payout sent, payout confirmed — writes one entry with the platform as actor. A failure writes a Failure entry with the error and the stage it failed at; a temporary failure leaves the batch at its current step, a final one moves it to failed. A retried step that changes nothing writes no entry, so the trail has no duplicates.
- Changes made through the AI assistant are recorded under the signed-in user who confirmed them.
Reading the history#
Open a record's detail page and choose Audit logs (on vehicles and drivers, Audit log). The page lists the record's entries newest first, 50 per page. Use the search box to find entries by action (its English code, such as "update"), record name, the person's name or username, or IP address, and Show to expand an entry's changes. A tenant's or merchant's history also includes its subscription's entries. A record with no entries yet shows "No audit entries have been recorded for this record yet."
These record types have an audit history page: purchase orders, work orders, vehicles, drivers, vehicle performance records, tenants, merchants, stores, services, SKUs, price lists, working shifts, tenant holidays, financial transactions, proforma invoices, VAT invoices, money movements, ledger entries, documents and subscriptions. User accounts and settlement batches are recorded but have no history page in the portal; the platform team reads those entries.
Permissions#
All nine portal roles hold the audit-log permission that shows the Audit logs action. Opening a record's history then needs both of the following:
- Permission to view that kind of record. Without it the page is refused. What each role may view is in What each role can do.
- The record is within your scope. A record of another organisation, or outside your assigned stores, answers "not found", so its existence is not revealed. The scoping rules are in Which records each user can see.
Platform team accounts can read the history of any record of a type they hold view permission for.
Rules#
- A merchant's internal history stays with the merchant. A tenant can see a partner merchant's stores, services, SKUs and price lists, but never their change history: a tenant user who asks for it gets "not found". A Merchant Supervisor reads the history of their assigned stores only.
- An inactive record keeps a readable history. Within your scope, an inactive vehicle, driver, store, service, SKU or working shift still opens its history, including the Inactivated entry.
- An import that rolls back writes no entries. The entries are written once, after the import's records are saved.