What a Compliant Audit Trail Looks Like in Field Service Software

A compliant audit trail in field service software is a history of each job that nobody can rewrite. It records which named engineer did the work, on which device, when they arrived and left and where they were, what they found, tested, fitted and photographed, who signed the job off, and which certificate was issued. Every change made after the visit is added alongside the original rather than replacing it. If your system can only show a job as it stands today, it cannot answer the question that matters when a visit is disputed: what did the engineer record on the day?

The Short Answer: What a Job-Level Audit Trail Records

For every job, a compliant field service audit trail keeps:

• Assignment history: who the job was allocated to, by whom and when, including every reallocation.
• Engineer identity: a named individual, never a shared van login or a tablet everyone uses.
• Device: which registered phone or tablet each entry came from.
• Two timestamps: the time on the device when the engineer recorded it, and the time the server received it.
• Location at the point of work: a position and its accuracy at arrival, departure and sign-off, or a clear note that no fix was available.
• Evidence: photos, readings, test results and the customer's signature, each tied to the moment it was captured.
• Parts used: what was fitted or consumed, against which job.
• Certificates issued: the document exactly as it was issued, with its number and the engineer who signed it.
• Immutable edit history: every later change with the old value, the new value, who made it, when and why.

The general principles behind this, and how they apply in other sectors, are covered in what a compliant audit trail looks like in business software. This page is about the parts that are specific to field service, and they are mostly about what happens away from the office.

Why the Job Is the Unit of Record

In office software, an audit trail usually follows a record: a customer, an invoice, a product formulation. In field service the thing that gets questioned is the visit. A customer says the engineer never turned up. An insurer asks what condition the boiler was in before a leak. A landlord's agent asks for the safety record for a property from two years ago. Each of those is a question about a job.

That shapes the design. A job should be modelled as a sequence of events (allocated, accepted, travelling, arrived, reading taken, photo added, part fitted, signed, certificate issued, closed) rather than as a single row whose status field gets overwritten. The current state of the job is then something you calculate from its events, and the history comes for free because nothing was ever thrown away.

What Happens at the Point of Work

Identity and device

The audit trail is only as good as its answer to "who did this?" Shared logins on a van tablet destroy that answer. Each engineer needs their own login, and each device should be registered so that an entry can be traced to the handset it came from. That also means that when a phone is lost or replaced, you can revoke it without affecting anyone else's history.

Time and location

Device clocks drift, and some people change them. Record both the time the engineer's device reported and the time the server received the entry, stored in UTC and shown in UK time. A gap between the two is normal for offline work. A device time that is later than the server time, or wildly earlier, is worth flagging.

Location is best captured at the events that matter (arrival, departure, sign-off) with the accuracy the device reported. If the engineer is in a basement plant room and there is no fix, the record should say so. A blank field and a missing reading look the same later on; an explicit "no fix available" does not.

Photos, readings and signatures

Photos are evidence only if you can show they were taken on that job, at that time, and not swapped afterwards. Store the capture time and location with each image and keep the original file untouched; if the image needs compressing for display, keep a derived copy. Recording a content hash when the photo arrives makes any later substitution detectable.

A customer signature needs context. Record who signed, their printed name, the time, and a copy of what they were shown when they signed. A signature against a job summary that was edited afterwards proves very little unless you can show the version they actually agreed to.

Parts used

Parts recorded against a job connect the visit to stock, invoicing and warranty. They also answer the question of what was fitted where, which matters when a batch of a component is later found to be faulty. Record the part, the quantity and, where you track them, serial or batch numbers.

Certificates: Issued Means Fixed

For gas and electrical work the certificate is often the document everyone cares about most, and it is the one most likely to be corrected after the fact. The rule is simple: once a certificate is issued, that version never changes. A correction produces a new version that references the original, and both remain retrievable.

The certificate should be generated from the readings and results recorded on the job, not typed separately, so that the certificate and the job history cannot disagree. Store the issued document itself, not just the data used to build it; if your certificate template changes next year, last year's certificates should still look exactly as they did when the customer received them.

Offline Capture and Sync Conflicts

This is where most field service audit trails quietly fail. Engineers work in cellars, loft spaces, rural properties and new-build sites with no signal. The app has to record everything locally and send it later, and in the meantime the office may be editing the same job.

Append, don't overwrite

If the engineer records a reading offline while someone in the office changes the job notes, a naive sync keeps whichever arrived last and discards the other. An audit trail cannot allow that. Because entries are events rather than overwrites, both can be kept. Where two changes conflict, such as two different values for the same reading, the system should keep both, flag the conflict and ask a person to resolve it. The resolution is then another event with a name against it.

Don't mark it done until the server has it

A common failure is an app that shows a job or checklist as complete on the device before the server has accepted it. If the upload then fails, the engineer believes the work is recorded, the office never receives it, and nobody finds out until something is missing. The device should hold every entry in an outbound queue, mark it as sent only when the server confirms receipt, and show the engineer clearly what has not yet synced.

Idempotent uploads

Mobile connections drop halfway through requests, so the same entry will sometimes be sent twice. Each entry needs a unique identifier created on the device, so the server can recognise a repeat and ignore it rather than record the reading twice.

Edits After the Visit

Office staff correct things: a mistyped reading, the wrong address, a job reopened because the customer rang back. None of that is a problem as long as the original is kept. Every edit should record the old value, the new value, who made the change, when, and a reason where the field is one that affects compliance. The audit records themselves should not be editable or deletable by anyone using the application, including administrators.

That gives you a point-in-time view: the job exactly as it stood on the day of the visit, alongside the job as it stands now.

The UK Regulations Behind It

No single regulation tells you to build a job-level audit trail. Several make one the practical way to meet them.

• Gas Safety (Installation and Use) Regulations 1998. Work must be done by an engineer on the Gas Safe Register, and landlords must keep a record of each annual safety check, including the date, the property, the engineer's name and registration number, and any defects found and action taken. Software that produces those records needs to tie them to a named, registered engineer and keep them unaltered.
• BS 7671 (the IET Wiring Regulations). Electrical installation work is certified on the model forms in the standard, with schedules of inspection and test results, signed by the person responsible. Generating the certificate from the readings recorded on the job keeps the two consistent.
• UK GDPR. The accountability principle means you have to be able to demonstrate how you handle personal data, which covers customer details and engineers' locations alike. Recording location at job events rather than tracking engineers continuously is easier to justify.
• HMRC record-keeping. Parts, labour and invoices recorded against jobs form part of the records supporting your accounts and VAT returns, so they need to be kept and to stay consistent with what was billed.

Retention periods differ between these obligations and your contracts, so agree them for each record type and have the system enforce them.

Scoping It for a Firm with Around 30 Engineers

A firm of five can often reconstruct a disputed visit by asking the engineer. At around 30 engineers that stops working: several office staff are editing jobs, engineers cover each other's work, and the person who did a job may have left. When writing requirements at that size, these are the questions worth answering first:

• Does every engineer have their own login, and is every device registered?
• Can the app work fully offline, and what exactly happens when two people edit the same job?
• Does the device show the engineer what has not yet synced?
• Are issued certificates stored as fixed documents, with corrections as new versions?
• Can you open any job and see it as it stood on a given date?
• Can you report across engineers, sites and date ranges without exporting to a spreadsheet?
• If you keep your existing field service product, can its data be brought into a system that does keep the full history?

The last point matters. Replacing a field app your engineers already know is not always the right move. Sometimes the better route is to keep it and integrate it through an API with a back-office system that holds the authoritative, append-only record. That is the kind of data integration work that sits alongside building custom applications.

A Real Example: Mobile Clock-In Feeding Head Office

Buxted Construction is a groundworks contractor rather than a field service business, but it has the same shape of problem: people working at remote sites whose records have to reach head office reliably. Site personnel clock in through iSOS, a third-party mobile workforce platform. A custom RESTful API is the integration layer between iSOS, the desktop application and a SignalR hub, so clock-ins flow to head office in real time and all external access goes through authenticated endpoints. The mobile clock-in data feeds timesheets for payroll preparation.

The lesson that carries across to field service is architectural: the mobile platform captures, the API validates and records, and the back-office system holds the history. Each piece can be checked on its own, and the record that matters sits somewhere the office controls.

Frequently Asked Questions

What does a compliant audit trail look like in field service?

It is a job-level history that cannot be edited. For every job it records who was assigned and by whom, which named engineer on which device did the work, when they arrived and left and where they were at the time, the readings, photos, signatures and parts recorded, any certificate issued, and every change made afterwards as a new entry beside the original. If a system can only show you the job as it stands today, it has a job record, not an audit trail.

How do you build a compliance audit trail into field service software?

Treat the job as a sequence of events rather than a single row that gets updated. Each event carries the engineer, the device, the time on the device and the time the server received it, and a location where one was available. Events are only ever appended. Corrections become new events that reference the one they correct, and issued certificates are stored as fixed documents, with any reissue creating a new version. Offline capture needs particular care so that a sync never silently overwrites what an engineer recorded on site.

What audit trail features matter for a firm with around 30 engineers?

At that size the office team is editing jobs while engineers are working on them, so the important features are: a named login for every engineer rather than shared devices, offline capture that syncs without overwriting, conflict handling that keeps both versions, certificate issue that cannot be quietly changed afterwards, and a point-in-time view of any job for when a customer or insurer asks what was recorded on the day. Reporting across engineers and sites matters more than it does for a firm of five.

What software provides a full job-level audit trail?

Some field service platforms provide one and many provide an activity log that looks similar in a demo. Ask any vendor to show you a job that was edited after the visit, and check that the original value, the person who changed it and the time are all still visible. Ask what happens when two people edit the same job while one of them is offline. Where a packaged product cannot meet your obligations, a bespoke system, or a bespoke layer integrated with the product you already use, can be designed around them.

Does GPS tracking of engineers raise GDPR issues?

Location linked to a named engineer is personal data, so UK GDPR applies. Recording location at the moments that matter to the job, such as arrival, departure and signature, is easier to justify than continuous tracking, and it is usually all the audit trail needs. Engineers should be told what is recorded and why, and the purpose should be documented, which is part of what the accountability principle asks of you.

How long should field service job records be kept?

There is no single figure. It depends on which obligations the job falls under: gas safety records, electrical certificates, contractual warranties, insurance and HMRC record-keeping each carry their own expectations, and UK GDPR requires that personal data is not kept longer than needed. The practical answer is to agree the retention rules for each record type with your advisers and have the software enforce them, rather than deleting by hand.

If you are writing requirements for field service software and want to work out what your audit trail needs to hold, get in touch. Development is billed on time and materials, so the conversation starts with what you actually need rather than a package.