100 Photographs, One Night Shift: Why Operational Field Applications Are Different
By Colin Yates, Director, WorkMobile
I recently spoke to a company that carries out inspections on the rail network. One of their inspectors can take up to 100 photographs during a single inspection.
Most of that work happens at night, often in poor weather, and always wearing safety gloves. Every one of those photographs needs context: what it shows, which check it relates to and where it was taken.
That conversation sums up why software used in the field is different from software used in an office.
It is easy to think of a field application as an office process running on a phone. In an office, the environment is predictable. The user has a reliable connection, a full-size screen and time to deal with something if it does not behave as expected. The rail inspector has none of those things. They are working in the dark, beside the track, with a signal that comes and goes, while trying to concentrate on the job they are actually there to do.
Having spent many years developing software, I think this is where apparently simple field requirements become more involved than expected. Putting a form onto a mobile device is rarely the difficult part. The challenge is making the whole process work in an environment where connectivity, evidence, working conditions and the movement of the job are all less predictable than they would be in an office.
The signal will drop. Plan for it.
For somebody at a desk, losing an internet connection is an interruption. For a field worker, it is often just part of the working day. Trackside, in cuttings, tunnels and remote stretches of line, coverage cannot be relied upon.
The application still has to work during that period. The inspector needs access to the job, the inspection form and any documents required on site. Everything captured while disconnected, including all of those photographs and the context attached to them, has to remain safely on the device and find its way back to the office when the connection returns.
Power Apps supports offline working, particularly through offline-first canvas apps using Dataverse. The developer still has to decide what information should be held on the device, what must be available while disconnected and how the application should behave when connectivity changes. Microsoft also places limits on how offline-first works depending on the application and data source being used.
At WorkMobile, where we provide a configurable platform specifically for field and operational workflows, offline working is already part of the mobile framework. The organisation decides which jobs, forms, documents and records its users need, but it is not designing the underlying method used to store and synchronise that information for every new workflow.
If people are expected to work where coverage is unreliable, the software cannot be designed on the assumption that a connection will always be there.
A photograph in a folder proves very little
Many office applications are mainly concerned with entering and retrieving information. Field processes usually need something more tangible: evidence.
Imagine reaching the end of that night shift with 100 photographs on a phone. Many of them will look remarkably similar, such as sections of track, fixings, signals and structures.
Without context, someone has to work out later which image belongs to which asset and which check. At best, that is hours of work for somebody in the office. At worst, it relies on the inspector’s memory of a long night in the dark, and the audit trail is only as good as that memory.
Now imagine each photograph being taken against the specific check it relates to, with the time, location and asset recorded automatically. The inspector does not type a label or rename a file. The context is captured at the moment the evidence is created.
That is the difference between digitising a form and digitising the work around it. The white paper makes the same point: for many field processes, the useful outcome is not simply data in a table but a complete inspection report or audit trail with the supporting evidence kept together.
The software has to fit the person wearing the gloves
A field application can be technically correct and still be awkward to use. Developers can miss this because applications are normally designed and tested at a desk, in good light, with a mouse and keyboard.
Put the same application in the hands of someone wearing safety gloves at 2am in the rain, and small things become big things. Small buttons, typing text, scrolling through long lists, extra taps to attach a photograph. Multiply even 20 seconds of extra effort by 100 photographs and the inspector has lost over half an hour, at the time and in the place where they least want to be lingering.
When a process is slow, people naturally find quicker ways of getting the work done. The photographs are taken on the phone’s own camera and sorted out in the morning. Notes go on a scrap of paper. Part of the record is left until later. The software may be behaving exactly as designed while the real process quietly happens somewhere else.
Most field users are not there to use software. They are there to inspect, repair or service something. The application is there to help them record that work, not to become the work.
So questions need to appear in an order that makes sense on site, information that is already known should not have to be entered again, and evidence should be requested at the point it is actually needed.
A process may be technically correct, but if it is slow or difficult to use, the result can be missing evidence, incomplete records or information being captured elsewhere.
The job does not end with the inspector
Field work rarely consists of one person completing a form and disappearing from the process. An inspection may be allocated to a named inspector, shared with a team or passed to a subcontractor. It may be started on one shift and finished on another. A defect found on the track may need office review, and a failed check could create a new piece of remedial work, which needs to carry the original evidence with it.
Documents also have to go with the job. Drawings, risk assessments, method statements and previous inspection records can all matter to someone arriving on site at night. If there is no reliable signal when they get there, those documents need to be on the device before they set out.
The application therefore needs to reflect how the work moves through the organisation: who receives the job, what they need before starting, what happens when it is completed and who reviews the result. Thinking only about the form misses most of what is happening around it.
What comes back to the office matters too
Capturing the information is not the finished job.
If the inspector’s 100 photographs arrive in the office as a pile of image files, somebody still has to match them to answers and assemble a report. The process may be digital, but a person is still piecing the finished record together by hand.
For many operational processes, the useful result is the complete record: an inspection report, service sheet or audit trail containing the answers and supporting evidence in a consistent format, ready for the client or regulator. The organisation needs to think about what the office, the customer or the auditor actually needs to receive at the end, rather than stopping when the data reaches a database.
Designed in the meeting room, used on the track
Operational field applications are different because they have to deal with things that rarely affect office software. Connections disappear. Evidence has to stay with the check it belongs to. Work moves between people. And the person holding the device is concentrating on something far more important than the application.
Power Apps can be used to build around those requirements. WorkMobile already includes many of these field functions because that is the kind of work the platform was designed to support. Power Apps provides the tools to design around these demands, while WorkMobile begins with many of them already accounted for.
The platform is only part of the issue, though. What really determines whether a field application works is whether the process has been designed around the people who will use it.
An inspection process can look perfectly workable on a laptop in a meeting room. The real test is whether it still works at 2am, beside the track, in the rain, with gloves on and 100 photographs still to take. Context should be captured at the moment the work is done, not added afterwards, and the software has to work in that environment, not the one in which it was designed.
This article is part of a series exploring the themes in WorkMobile's white paper, Power Apps Can Build Almost Anything. But Should It?
