Losing a phone during an inspection is not supposed to be part of the workflow.
But phones get lost.
They get broken.
They get left at the office.
They get dropped.
And, occasionally, they get dropped somewhere considerably worse.
So what happens to an inspection that is already in progress?
This is one of those situations where the design of the system matters much more than a feature list suggests.
The inspection isn’t trapped inside the phone
Once a survey is downloaded to a device and work begins, information can be synchronised with the main server as the inspection progresses.
That means the server may already hold a substantial part of the survey even though the inspection has not yet been submitted.
The information isn’t necessarily sitting entirely on the phone waiting for the final submission.
This is important if the device suddenly disappears.
Recovering a survey already in progress
BrightChecker provides a way for authorised users to see surveys that are still in progress.
The system can show the information that has already synchronised, including the responses and media that have reached the server.
So if the phone has been lost, damaged or is simply unavailable, you can assess what is already there.
You can then tell the system to take that synchronised information and continue from it rather than simply abandoning the work.
That doesn’t magically recover information that never reached the server.
But it does mean that a device failure doesn’t automatically mean the entire inspection has been lost.
Why synchronisation matters
This is another reason why the synchronisation queue is important.
If everything were held locally until the final submission, losing the device could mean losing everything.
Instead, the system continuously works to move completed information back to the server.
The more successful synchronisation that has taken place, the more of the inspection is already protected centrally.
That is a much more sensible approach to fieldwork.
What if the device is only temporarily unavailable?
Perhaps the phone isn’t actually lost.
Maybe it has been left at the office.
Maybe the battery has failed.
Maybe the inspector has moved to another device.
The same principle applies.
You can see what information has already reached the server and make a decision about how to proceed.
What if something goes wrong with the submission itself?
This is where the rest of the BrightChecker design connects together.
The synchronisation queue, the recovery of work in progress and the ability to deal with individual pieces of information are all part of the same philosophy.
We don’t want one failure at the end of an inspection to destroy everything that happened before it.
Field software should assume that things occasionally go wrong.
Designing for the bad day
Most software demonstrations happen on a perfect day.
The connection is strong.
The phone is charged.
The device is in your hand.
Nothing goes wrong.
Real inspections aren’t like that.
The useful question is not:
“What happens when everything works?”
It is:
“What happens when something doesn’t?”
That is why device recovery and synchronisation are important parts of the BrightChecker design.