Skip to content
All insights

Energy

Field Data Capture Where There Is No Signal and No Spare Hands

By Vivek S N · 9 December 2025 · 5 min read

Photograph by Jakub Pabis on Unsplash

There is a recurring, expensive pattern in industrial software. A company decides to replace paper inspections, permits or compliance records with an application. The requirements are gathered from supervisors, compliance managers and the people who will read the reports. The application is built to those requirements. It is correct, it is comprehensive, and the field does not use it — they keep the paper and type it in later, or they fill in the app in the site office from memory at the end of the shift.

Both of those outcomes are worse than the paper, because now the record has an electronic timestamp implying it was captured at the point of work when it was not.

We have built in this space — including for oil and gas operations, and a unified platform for workforce compliance and training across health, safety and environment — and the failure is almost never in the data model. It is in the gap between who specified the application and who has to use it.

Connectivity is the wrong assumption, in both directions

Industrial sites do not have reliable coverage. Not intermittently — structurally. Inside a tank, under a deck, in a plant with a lot of steel between the user and any antenna, there is no signal, and there will not be one because installing coverage in a hazardous area is a capital project.

Everyone knows this and it still produces broken software, because "offline support" gets scoped as a degraded mode rather than as the normal mode. The application assumes connectivity, notices it is missing, and enters a fallback state with a subset of functionality and a warning banner. Since the fallback state is where the work actually happens, the user spends their entire day in the degraded version of the product.

The correct framing is the reverse: the device is authoritative, holds everything it needs, and synchronises opportunistically when it happens to have a connection. The user should never be told about connectivity, because they cannot do anything about it and the software should not need them to.

That also means reference data has to be resident — the asset register, the procedures, the checklists, the valid values, the previous inspection for comparison. An inspection form that needs a lookup from a server to populate a dropdown is a form that cannot be completed where the asset is.

The interface has to survive a glove and a wet screen

Physical conditions eliminate large parts of the standard interaction vocabulary.

Gloves make small touch targets unusable and defeat some capacitive screens entirely. Rain and hydraulic oil on a screen generate spurious touches. Direct sun makes low-contrast interfaces invisible. Cold makes fine motor control worse. The user may be at height, in a harness, holding a rail with one hand.

The consequences are unromantic and non-negotiable: large targets, high contrast, no gestures that require precision, no drag interactions, no interface element that depends on a hover state. Free-text entry should be minimised, not because the worker cannot type but because typing on a phone in that environment is slow enough that they will skip the field. Structured input — a choice from a list, a photograph, a scan — costs seconds. A text box costs a minute and often gets a single word.

Photographs deserve emphasis, because they are the highest-value and cheapest input available. A picture of a corroded flange communicates more to a reviewing engineer than any description a busy inspector will write, and taking one requires no literacy, no language and no typing.

The report is not the point of capture

The most common structural error is designing the capture form to mirror the output document.

The compliance report has a shape, mandated by a regulator or an internal standard, and it is tempting to make the app collect the fields in that order. But the report's order is the order a reader wants, which is organised by topic. The inspector's order is the order the physical world presents things, which is organised by where they are standing.

An application that makes someone walk the length of a unit, come back for one reading, and walk it again has lost the argument regardless of how correct its data model is. Capture should follow the route. Assembling the report from what was captured is the software's job, not the user's.

The same reasoning applies to mandatory fields. A field that cannot be answered where the user is standing — because the information is elsewhere — must not block submission, or the user learns to enter something untrue to get past it. That is worse than a gap, because a gap is visible and a plausible fabrication is not.

What the record has to prove

Industrial compliance records exist to be relied upon later, sometimes in an investigation or a legal proceeding. That sets requirements the desk-side specification usually omits.

The record needs to show when it was captured, not when it was uploaded — those can be days apart and the difference is the entire question in an investigation. It needs to show who captured it, in a way that is not simply whoever was logged in on a shared device. It needs to show where, which on a site means better than a several-metre position, and often means scanning a tag on the asset rather than trusting satellite positioning inside a steel structure.

And it must be tamper-evident. If a record can be edited after the fact with no trace, its evidential value is limited. Corrections have to be possible — people make mistakes — but as an appended correction with its own author and time, never as a silent overwrite of the original.

Device clocks are a real problem here, since they can be wrong and can be changed. Capturing the device's time alongside the server's time at sync, and recording the difference, is the cheap way to make a discrepancy visible rather than invisible.

The test that predicts success

The strongest predictor of whether one of these projects works is whether anybody who will use it was involved before it was built, and whether it was tested where it will be used.

Not in a meeting room. On the site, in the weather, wearing the equipment, by someone who does the job — with a stopwatch on how long a routine inspection takes compared to the paper form it replaces. If it is slower, it will be worked around, and every subsequent conversation will be about compliance and training when the actual problem is that the software costs the user time they do not have.

That test is cheap, and it is skipped almost every time.


iLeaf builds field, compliance and industrial applications for energy and infrastructure operators, alongside fifteen years of mobile and cloud delivery. See the work or tell us about the project.

Thinking about this for your own business?

We have been building and running enterprise systems since 2011. Talk to a solutions lead about where agents pay off first.

Talk to a solutions lead