Field Inspection Forms with Photo Evidence

Inspection photos often end up in messages while the checklist and follow-up work live elsewhere. I build a field form that connects each checklist item to its evidence and each finding to an assigned action. A photo belongs to a specific observation, rather than becoming an unexplained attachment in a folder.

The application records your inspection method and the decisions of the relevant specialists. Completing a checklist or uploading a photograph does not itself certify that a site is safe. Your responsible team defines the criteria and decision authority.

Example: Shelf fixing at site S-12

The illustration shows a fictional inspection of S-12. The exit route passes, lighting passes, and shelf fixing has an issue. The photograph is attached to that shelf finding. Follow-up action A-31 is assigned to Can, with a target date of 8 October.

The two passing answers do not cancel the failed item. Submitting the inspection does not complete A-31. Can can record a correction and add new evidence; who may confirm closure is a separate rule. The original and follow-up photographs retain their respective places in the sequence.

Give each item the fields it needs

Some checks only need a yes or no. Others require a measurement, explanation or photograph. An issue can reveal mandatory reason and action fields, while not applicable can require a justification. An unanswered question must remain distinct from a deliberate not-applicable answer, so an incomplete form cannot appear complete.

The checklist version stays with the inspection. Adding a question next month should not rewrite an earlier record. Evidence records retain their uploader and related finding. If location or time information is needed, its purpose, presentation and access are defined separately. I do not assume that every image contains dependable location or capture metadata.

When an existing form is enough

Google Forms and similar tools can support basic checklists and file collection. If gathering answers meets the need, a custom application may be unnecessary. It becomes useful when ownership, correction, reinspection and site-specific access must work together. Offline operation requires its own design and device testing rather than being assumed as standard.

Making the scope testable

I start with a de-identified example of your current file or screen and the roles of the people using it. The written scope defines where each field comes from, who can change it and where the result goes. I test missing evidence, a not-applicable answer and A-31 marked complete but not yet verified. The phone’s submission result must correspond to the record actually stored.

The scope also covers exports, the backup approach and who handles failures. We review the first version against one real workflow before planning further connections.

Frequently Asked Questions

Must every issue have a photograph?

The rule can vary by item. I avoid unnecessary uploads when a written explanation is sufficient, while keeping missing required evidence visible on checks that need it.

Does marking an action complete close the inspection?

A separate verification role can be included. The person making the correction and the person accepting it may be different, with both actions visible in the same record history.

What happens if the phone loses its connection?

Without offline scope, the screen must clearly show that submission is still pending. If offline capture is required, synchronising files and answers when connectivity returns needs separate implementation and testing.

Discuss your workflow

For a related workflow, see Quality Inspection Measurements and Exceptions. Explore custom web applications for your team or contact me with an example of the process you want to improve.