How Can Periodic Inspection Records Be Kept Safely When There Is No Internet?

Short answer: how is an inspection record kept without internet?

Save the inspection form to a transactional local database on the device; give each record a unique transaction identity, keep the submission status visible, and reconcile with the server without duplicate creation once connectivity returns.

In offline operation, "saved" is not a single state. To the user, the states saved to device, pending submission, accepted by server and review required must be shown separately. This way, the form appearing on screen under weak connectivity is not assumed to have reached the head office.

Which data should be taken onto the device before going to the field?

Short answer: only the current and authorized data package needed to complete the assigned job should be taken.

• The work order and the immutable equipment identity
• The pinned version of the inspection form tied to the equipment type
• The required inspection criteria and selection lists
• The assigned personnel's task scope and device references
• The last synchronization time and the package version

The W3C Service Workers specification explains that offline web applications can be built with a worker intercepting requests and a local request/response store. The counterpart in the VizyonTech workflow is not merely caching the page shell but preparing the assigned job's form and reference data as a pre-field verified package.

If the package is not current, the application must not silently open an old form. The last synchronization time, form version and offline usage limit must be visible. If critical master data is missing, the system must block record creation, following the fail-closed principle. The relationship between work orders, equipment and forms is explained in the periodic inspection plan guide .

How should the form be saved on the device?

Short answer: write every field change not to temporary screen memory but to a short, atomic local database transaction.

The W3C IndexedDB 3.0 draft defines that, for offline web requirements, structured objects are held locally and transactions are either written in full or rolled back on error. In the field form, this means the measurement value, unit, description, photo link, and record time are written to a consistent draft version.

The save button must show success only when the local transaction is complete. The application closing, the battery running out, or connectivity momentarily returning must not move a half-finished form into a "submitted" state.

How should synchronization be done when connectivity returns?

Short answer: send the queue in order, retry each item with the same transaction identity, and mark as complete only after the server's explicit acceptance response.

1. Verify not just the presence of connectivity but access to the application server.
2. Re-check the local integrity and mandatory fields of the record in the queue.
3. Send the record and its attachments with the immutable transaction identity and local version.
4. Run the server's authorization, work order, form version, and current record version checks.
5. On successful acceptance, write the server record identity and acceptance time to the device.
6. Route transient errors to controlled retries and persistent validation errors to human review.

RFC 9110 explains that an idempotent request can be repeated after a connection error with the same intended effect. In a periodic inspection record, the method name alone is not sufficient: the server must not add a second request arriving with the same transaction key as a new report; it must return the previous acceptance result.

The Background Synchronization API can defer the job to a service worker when connectivity returns; however, MDN marks this as a feature without broad browser support. For this reason, the queue must not depend only on a background event; it must also work reliably at application start and on the user's "send now" action.

What happens if the same record is changed on two devices?

Short answer: do not use a last-write-wins approach for measurement and conformity fields; stop on version conflict and show both changes to the authorized user.

If the server-side version is ahead of the base version the device received when starting the job, automatic overwriting can cause data loss. Non-conflicting fields can be merged in a controlled way; if the same measurement, result, or critical description has changed on both sides, the record must be put into the review required state.

• Compare the server version with the device's base version.
• Keep the changed fields and actors in the audit trail.
• Do not silently replace a published report with an offline draft.
• Record the conflict resolution as a new revision with a justification.
• Clearly show the user which device's record is waiting.

How should offline data be protected on the device?

Short answer: download only the necessary data, protect local data with the platform's secure storage, and apply controlled cleanup tied to the device/session life cycle.

OWASP MASVS-STORAGE-1 requires sensitive data to be stored securely regardless of its location on the device. MASWE-0006 recommends not keeping unnecessary sensitive data locally, protecting keys in the platform's secure key store, and using appropriate encryption.

• Take only the assigned job into the offline package, not the entire customer archive.
• Protect session keys, personal data, photos, and measurement attachments according to their data class.
• Do not keep the encryption key next to the data file or in source code.
• Test device loss, user change, and authorization revocation scenarios.
• Clean up submitted local attachments safely according to the retention policy.
• Do not write sensitive records to shared file areas or uncontrolled backups.

Offline operation does not remove authorization checks. Even if the device was previously authorized, the server must re-verify the user, organization, work order, and form version during synchronization.

Which scenarios should be tested before going live?

Short answer: an airplane-mode test is not enough; it must be proven that an outage occurring at every stage of the record is handled and that retries do not create duplicates.

1. Does the application open while offline for the first time, or does it correctly report the missing preparation?
2. If the application closes during field entry, is the last completed local transaction preserved?
3. If the connection drops while a photo is uploading, does the link between the form and the attachment break?
4. If the server accepts the record but the response does not reach the device, does resubmission open a second record?
5. When the form version changes at the head office, how is the old offline job resolved?
6. When the same job is edited on two devices, does a critical field conflict stop the process?
7. When a user whose authorization was revoked reconnects, is the submission rejected while the record is preserved?
8. When the queue waits for days, can the user understand which records are not at the head office?

Vizyon Periyodik In the evaluation, the offline feature should be tested not just with a "form opens" demo but together with local commit, a visible queue, idempotent acceptance, conflict management, and device security. For other fail-closed gates in software selection, use the periodic inspection software selection guide you can explore further.