NDT Field Software: Test Offline Work and Synchronization
Offline support is a claim about a particular workflow, not a promise that every function works without a connection. Test the tasks, evidence and synchronization behavior your inspection team actually needs before adopting a field application.
For: U.S. NDT equipment coordinators, quality staff and inspection business owners
Define what must continue without a connection
Start with a list of field activities that cannot depend on reliable connectivity. The list might include opening an assigned task, viewing the approved drawing, recording an observation, attaching a permitted image or retaining a measurement reference. The responsible inspection team decides which activities belong in the workflow. The buyer should distinguish those essentials from functions that can reasonably wait until the device reconnects, such as administrative reporting or broader project review.
Describe the expected offline period and working context using the organization's real conditions. Avoid a vague requirement that the application work anywhere. The evaluation needs to know whether a user will prepare tasks in the office, change locations during the shift or work without access to the central system for an extended period. These conditions affect what must be available locally and which changes may occur elsewhere while the user is disconnected.
Name the authoritative record for each stage. A local draft, a synchronized record and an issued report may have different status. The team should know when an observation is merely saved on one device and when it has reached the central record. This distinction is central to the purchase decision because it affects supervision, recovery and what the organization can truthfully describe as complete.
Read product claims at the application and version level
Manufacturer information can help identify useful candidates, but a platform description rarely answers every offline question. Evident's Connect overview describes project and mobile workflow functions. Its 39DL PLUS page describes an IPM mobile workflow that can operate with or without an internet connection. These are manufacturer statements about named products, not evidence that every function in a proposed implementation is available offline.
Ask the supplier for the exact application version, supported device environment and configuration used in the demonstration. If the workflow includes an instrument connection, cloud service and mobile application, identify all of them. The accepted result should apply to a defined combination. A successful test on one operating system or application edition should not silently become a claim about every device the business owns.
Separate documented capability from demonstrated behavior. A supplier may provide clear documentation for a function that your team has not yet exercised. Record that status honestly. For business-critical offline work, a controlled sample exercise can reveal practical dependencies that a feature list leaves unclear, such as whether a task must be opened once online or whether large supporting files are available locally.
Prepare a small fictional project with expected outcomes
Create a test project containing a few clearly labeled fictional tasks and nonconfidential supporting files. Include the types of identifiers, notes and attachments that matter to your workflow. Define the expected outcome for each case before testing. This makes the exercise reproducible and prevents the team from accepting whatever behavior happens to occur as though it were the original requirement.
Assign separate test roles where the application supports them: a field user, a coordinator and a reviewer. Use the permissions intended for those roles rather than evaluating everything through an administrator account. A feature that works for an administrator may be unavailable or behave differently for the person who will use it in the field. The purchasing record should identify the role used for each observed result.
Keep the test isolated from real production records. Use an approved evaluation environment or clearly separated sample project, and follow the organization's device and application rules. The objective is to test ordinary record behavior without creating confusion in a customer's inspection history. If the supplier must perform part of the test, retain enough evidence to show what was done and which requirement it addressed.
Verify preparation before disconnecting
Ask the field user to prepare the assigned sample work through the documented process. Confirm that the correct task version, drawing and required reference material are available. Then evaluate the prepared state without a connection under the agreed test plan. The supplier should explain which preparation steps are required and how the user can tell that preparation has completed successfully.
Include a task the user has not previously opened if that reflects the intended workflow. This can expose whether availability depends on a hidden prior action. Also include a supporting object that is materially different from a short text note, such as an approved sample image or drawing. An application may retain task text locally while handling associated files differently, so the evaluation should inspect the actual objects the team needs.
Record any limitation as a preparation requirement or a failed capability, depending on the business need. A system can be useful if it requires a clear download step before travel. It may be unsuitable if staff cannot reliably perform that step and the required evidence is unavailable afterward. The buyer should make that judgment explicitly rather than assuming that an offline label removes all preparation responsibilities.
Observe how local saving is communicated
Have the test user create the agreed sample observations while disconnected and inspect the application's saving indicators. The user should be able to distinguish information retained locally from information synchronized centrally. A clear indicator supports a practical handover at the end of a shift. If the interface does not make the distinction obvious, ask the supplier to explain the behavior and assess whether training or an external check is sufficient.
Reopen the sample task through the documented workflow to confirm that the expected local information is available. The exercise should include the actual object types being evaluated, not only a short note. Record whether attachments, measurement references and identifiers remain associated correctly. Do not infer that all data have been saved because one visible text field remains on screen.
Ask what happens when the application session ends or the device requires routine recovery. Use only an approved, controlled test and preserve the sample evidence. The purpose is to understand the retention boundary, not to damage a device or interrupt real work. The supplier should identify what can be recovered locally, what depends on prior synchronization and which actions the user must avoid until pending records are resolved.
Test reconnect behavior and completion signals
Reconnect through the agreed test process and observe how pending records reach the central system. Compare the local sample with the coordinator's view. The expected result should include the correct task identity, content and relevant attachments. Record whether synchronization is automatic, requires a user action or has conditions that the team must understand. The important point is a known workflow with an observable completion state.
Do not treat disappearance of a progress indicator as the only evidence of success. The receiving role should confirm the expected records in the central project and inspect a representative attachment. A transfer can appear complete from one screen while a required object remains unavailable to another role. The acceptance exercise should follow the information to the place where the organization will actually review and issue it.
Include a deliberate retry of a sample transfer where the product's documented workflow permits it. Determine whether the system recognizes the same record, creates a duplicate or asks for a decision. The buyer needs to understand this behavior before users improvise retries during a real connectivity problem. Record the supported response and the owner of unresolved synchronization issues rather than guessing that repeated attempts are always harmless.
Evaluate conflicting edits without assuming a universal policy
If more than one person may change a task, include a controlled conflict case. For example, a coordinator edits a fictional task while a field user's prepared copy is disconnected. The expected outcome should be defined with the supplier and project owner. Some systems prevent certain concurrent changes, some retain versions and some ask a user to resolve the difference. Do not assume one approach from a generic collaboration claim.
Inspect what information is preserved and what the user is told. A conflict result should be understandable enough for the responsible person to decide what belongs in the current record. The organization should know whether either version is overwritten, retained separately or marked for review. A technically successful synchronization can still be a poor fit if the team cannot explain which instruction or observation became authoritative.
Assign conflict resolution to an appropriate role. The field user may be able to identify the work performed, while a coordinator controls scope and a technical reviewer approves the result. The application should support the agreed responsibility or the organization should define a controlled external process. Avoid giving every user broad edit authority merely to make the demonstration proceed smoothly.
Keep scope changes separate from collected observations
A project can change while a user is offline. Ask how the workflow communicates a withdrawn task, revised drawing or changed location list after reconnection. The organization needs a way to distinguish observations collected under an earlier instruction from work performed under a revised scope. The purchasing test should preserve that relationship without pretending that the software itself decides whether the earlier work remains technically acceptable.
Use a fictional revision case to demonstrate the record. Retain the original task reference, the change and the collected sample observation. Ask the reviewer to explain which version applied when the observation was made. If the software cannot retain enough context directly, identify the external record required and assess the burden. A process that depends entirely on remembering when a phone last connected is difficult to review later.
Do not automatically relabel earlier observations as though they were collected under the latest instruction. The technical and project authorities determine the appropriate disposition of affected work. The software evaluation should establish that the necessary evidence can be retained and communicated. This is a distinct requirement from making every device display the newest task title as quickly as possible.
Check report readiness and approval meaning
Define what the application's completion states mean. A task marked complete may indicate that a field user finished entry, that data synchronized, that a reviewer approved it or something else. Those meanings should be explicit in the organization's workflow. Ask the supplier to show how the status changes and what permissions control each action. Do not describe a digital sign-off as technical approval unless the actual process gives it that meaning.
Generate a sample report before and after synchronization under the controlled test plan. The reviewer should understand whether the report includes pending local information, only centrally available information or a defined reviewed subset. A live project dashboard can be useful while remaining incomplete during disconnected work. The organization should avoid issuing a report that appears final while required records are still held only on a field device.
Retain a clear boundary between a working report and an issued record. If the application updates reports dynamically, decide how the issued version is preserved and identified. The buyer should know which functions the product supplies and which document control responsibilities remain outside it. Automatic updates can reduce administrative work without eliminating the need for an identifiable approved deliverable.
Include access changes and device handover in acceptance
Ask how a role change or account removal affects pending local records. The organization may need to collect unsynchronized work before a device is reassigned or a user leaves a project. Evaluate the supported administrative process with fictional data and the application's authorized administrator. Do not assume that disabling an account automatically recovers every locally retained observation or that a new user should inherit the previous user's active work.
Document a routine device handover checklist based on the observed behavior. It should identify pending records, the central confirmation needed and the person responsible for closing the handover. The checklist is an original operational administration artifact for the chosen software, not a universal instruction to erase or reset devices. Follow the organization's approved device management process for any cleanup or reassignment actions.
If the workflow depends on shared devices, test the intended user transitions explicitly. The record should retain the attribution required by the organization and avoid confusing one person's local draft with another person's work. If the application supports only a different model, such as individually assigned devices, include that requirement in the ownership cost and deployment plan rather than improvising an unsupported sharing arrangement.
Make the purchasing decision from the observed workflow
Summarize each case with the requirement, observed behavior, evidence location, limitation and owner. Separate essential offline capabilities from conveniences. A missing decorative dashboard feature may be acceptable, while inability to retain the required drawing or distinguish pending records may prevent adoption. The decision should explain the significance of each limitation in the organization's actual work rather than relying on a generic score assembled from feature counts.
Include required devices, subscriptions, preparation time, user instruction and support responsibilities in the purchase review. Do not call a workflow free because an application can be downloaded without charge. Confirm the terms and entitlements relevant to the proposed package. Likewise, do not invent a universal productivity gain from removing paper; evaluate the actual work involved in preparation, reconciliation and review.
A fictional team might accept an application that requires tasks to be prepared online because that step fits its daily planning. Another fictional team might reject the same limitation because its assignments change after leaving connectivity. Neither decision proves the software universally good or bad. The useful outcome is an evidence-based fit between the product's demonstrated behavior and the team's defined field workflow.
Keep NDT Connect's role clear
The free NDT Connect equipment tracker is an equipment administration tool with identity fields, calibration due date, status and notes. It is not the mobile inspection system evaluated in this article, and it does not provide the offline task, drawing, attachment or synchronization functions described as buyer questions. Keep inspection observations and approved reports in the selected system that has been evaluated for those purposes.
Use the equipment record to identify the instrument and point to the external software acceptance evidence where helpful. Maintain the accepted application versions and integration dependencies through the organization's change process. A later application update should prompt an appropriate review of the cases it may affect, rather than an assumption that either every change is harmless or every change requires repeating unrelated work.
The acceptance package should let a new coordinator answer three practical questions: what must be prepared before leaving connectivity, how staff know their records have reached the central system, and who resolves exceptions before a report is issued? When those answers are supported by a controlled demonstration and an owned process, the organization has a useful basis for adopting field software without overstating what offline support guarantees.
Frequently Asked Questions
Does offline support mean every app function works without internet?
No. Identify the exact tasks and supporting objects required, then test them in the proposed application version and device environment.
Is a record saved locally already part of the central project?
Not necessarily. Confirm the product’s saving and synchronization states and verify the expected record in the receiving environment.
Does NDT Connect provide the offline inspection workflow described here?
No. The guide evaluates capabilities to ask of inspection software. NDT Connect’s free equipment tracker provides equipment administration fields, not offline inspection task synchronization.
References & Standards Cited
- Evident: Connect cloud applications and project workflow capabilities View source ↗
- Evident: 39DL PLUS connected workflow and IPM mobile offline description View source ↗
Related on NDT Connect
Join NDT Connect — free
The free marketplace for the NDT industry — connect inspectors and the companies that need them.
Free to join · Compare provider qualifications and confirm availability directly · Browse providers
By NDT Connect Editorial · Updated
Source-based editorial guidance. Read our editorial policy and disclosures.