How do you collect feedback offline and keep it connected?

Prepare the form and permitted reference data before leaving connectivity, save each visit with its own ID, and verify synchronization before deleting the local copy. If you need to follow the same person, household or partner over time, also define a stable subject ID and a process for resolving uncertain matches. Offline capture and longitudinal identity are separate requirements.

Use this reference when your collection plan includes intermittent connectivity or imported field batches. Test whether the record design survives a field visit, a device change and a delayed upload. Your deliverable is a short field protocol and a reconciled test batch.

Start with the visit, the subject and the submission

Consider a fictional fieldworker visiting one household in March, July and November. The household ID identifies the unit being followed. A visit ID distinguishes each encounter. The form version identifies the questions asked. The submission ID identifies the uploaded response. These identifiers serve different purposes and should not be substituted for one another.

A tablet’s upload order does not establish event order. Record when the visit occurred separately from when the response reached the server. If a different household member answers, retain the appropriate respondent role rather than assuming the same person supplied every answer.

Missing identifiers make reconstruction harder, but they do not prove that all earlier evidence is lost. Authorized reconciliation may be possible using adequate source information. Keep uncertain matches visible and explain how unmatched records affect the analysis; do not silently force a match to complete a chart.

Choose what must work without a connection

Write down the actual offline tasks: open a form, select an existing household, add a new participant, save an attachment, validate a response and resume an interrupted visit. A product supporting one task offline does not mean every lookup, file type or analysis feature works offline.

KoboToolbox’s web-form documentation requires opening and caching a form while connected before offline use. Responses can queue locally and upload after reconnection. Its guidance warns that clearing browser site data can delete queued work. Test the exact browser and device your team will use.

KoboCollect’s Android documentation describes downloading deployed forms before collecting without a connection. Draft, finalized and sent responses represent different stages. Train fieldworkers to recognize which state a record is in, rather than treating “saved” as “received by the central team.”

These are examples of documented field-tool behavior, not a promise that every platform behaves the same way. For a Sopact workflow, agree whether collection is native or supplied through an approved field-tool import, and test the complete route to the continuing record.

What an identifier has to survive

Design the ID for the unit you follow. A household splitting into two households is not the same situation as a person changing phone number. Record a documented relationship or change event when the real-world unit changes; keeping the old label alone may misrepresent the history.

Can respondents create their own identifiers?

Self-generated codes can be considered in some study designs, but test their stability, uniqueness and disclosure risk. People may interpret the instructions differently on later visits, and two people may generate the same code. A code derived from family names or birth information is not automatically anonymous.

System-issued codes also need a retrieval process. A card can be lost, a link can be forwarded and the wrong roster entry can be selected. The practical question is not which approach can never fail. It is how the workflow detects uncertainty, supports authorized recovery and prevents an uncertain match from becoming a confirmed fact.

Do not rely on a phone number or name alone. Numbers can be shared or reassigned; names can be transliterated differently. Use the minimum information appropriate to the purpose, with a documented matching rule and review route for exceptions.

Prepare a field protocol before the first visit

1. Define the unit and ID. State whether you follow a person, household, facility or partner. Decide how repeat visits connect and how a genuinely new unit is registered.
2. Prepare permitted reference data. Provide only the roster information the fieldworker needs. Test whether it remains available offline and how updates reach the device.
3. Prevent ID collisions. If issuing codes offline, use an agreed unique-ID method or allocated ranges across devices and sites. Test the same new-registration scenario on two devices.
4. Load and test the right form version. Check language, branching, required fields, ranges and attachments without a connection. Keep the version with each response.
5. Explain local storage. Fieldworkers should know how to save, resume, finalize and confirm an upload. They should also know what actions could remove unsent records.
6. Plan exceptions. Define what happens after a lost device, interrupted visit, duplicate registration, changed permission or failed upload.
7. Reconcile the batch. Compare expected submissions, local queue status and accepted server records. Resolve discrepancies before removing local data under the agreed retention procedure.

A simple roster can work for a small team, but its maintenance still needs an owner. If a mapping links codes to identifiable people, control access and keep the analytical view appropriately separated. Avoid printing sensitive program information on a card that could expose a participant if found by someone else.

What changes when two devices are offline?

Device A may record a new address while device B holds an older roster. When both reconnect, the server needs a policy for updates and conflicts. “Last uploaded” is not necessarily “most recent event,” and a silent overwrite can hide a valid observation.

ODK documents Entities for longitudinal and case workflows, including information shared between forms and conflict handling. Its documentation also describes offline entity updates in supported versions. Use the documentation for your selected field tool to design the test; verify your exact relationships, permissions and conflict handling rather than relying on the feature name.

Test a late submission, a repeated upload and two different updates to one subject. Preserve distinct visit records. If a current attribute is updated, keep enough history to explain which source supplied it and how a conflict was resolved. Do not count an upload retry as another visit.

Practice: reconcile a partner’s field batch

Use fictional Partner P-024 for this exercise. A partner’s field team makes three authorized visits. Two devices synchronize in a different order from the visits, and one upload is retried. The exercise concerns visit records; it does not change the separate Q3 definition of program completion.

The expected result is three visits across two households, assuming the IDs and retry status have been validated. There are four transmission attempts in this example. A transmission count is not a participant, household or visit count.

Add one conflicting address update and one record with an unrecognized subject ID. Do not invent the answer that makes the total reconcile. Record the conflict, retain the source and ask the authorized reviewer to resolve it. Your batch note should state what was accepted, what remains unresolved and whether any record is excluded from a report.

Privacy: a linked record is not necessarily anonymous

Replacing a name with a code may protect some uses of the data, but a retained mapping can still identify the person. The UK Information Commissioner’s guidance distinguishes pseudonymisation from anonymisation and emphasizes protecting the additional identifying information. Do not describe a follow-up system as anonymous simply because the report hides names.

Agree what participants are told about collection, follow-up, access and retention. A request not to receive future contact is different from a request affecting already collected data. Follow the applicable protocol and requirements for each request; do not automatically erase the history or continue contact merely because the ID exists.

Offline devices may not have the latest permission status. Define how fieldworkers obtain current instructions and how the team handles a status change while devices are disconnected. Before providing data to an assistant, continue with the lesson on AI access to stakeholder data.

What should you verify when choosing a tool?

• Which forms, reference lists and attachments are available offline on supported devices?
• Can staff distinguish a draft, a queued response and a confirmed server receipt?
• How are new IDs issued across sites, and how are duplicates or uncertain matches reviewed?
• How are late updates, retries and conflicting edits handled?
• Does export preserve subject, visit, submission and form-version information?
• What happens to unsent work after a restart, low storage, logout or loss of the device?
• Can the receiving workflow keep source files, dates and permissions with the right record?

Do not assume an XLSForm import preserves every feature in another product. Test a representative form containing its actual calculations, repeat groups, translations, media and validation. If you use exports instead, document the field mapping and reconciliation rules. Confirm the supported integration before promising a migration route.

The role of Sopact in this workflow is to make the collected evidence useful in its continuing context. Test the configured route from field submission to the appropriate contact or partner record, then to the analysis and report. A rejected attachment, ambiguous date or uncertain ID should remain a review issue; AI analysis should not conceal it.

Run the test before field deployment

Use a safe test environment with representative history. Put two devices offline, complete the fictional batch, restart one device, reconnect in reverse order and inspect the received records. Test the actual form features and the permissions needed by each role.

Pass when every expected visit can be accounted for, duplicates are handled according to the documented rule, uncertainty is visible and the source context survives. Human review of an ambiguous case is not failure. An unnoticed merge or missing submission is.

After the test passes, release the field protocol and check the first real batch closely. Keep a named owner for synchronization problems and unresolved identity questions. Connectivity, battery, storage and staff training remain operational concerns even when the software supports offline capture.

Watch: why collected evidence needs its record context

Watch the video · 2 minutes 34 seconds. This is a companion explanation of connected evidence, not a demonstration of offline device support. Use the field test above to verify offline behavior in your chosen configuration. Explore more explainers in the video library.

Frequently asked questions

Can a survey work with no internet connection?

Some tools can collect offline after the form and needed reference data are downloaded or cached. Test the supported device, browser and form features before deployment. An ordinary online link does not necessarily work offline.

Is saving a response the same as uploading it?

No. A draft or locally queued response may not have reached the server. Confirm receipt and reconcile the expected batch before removing local copies under the retention procedure.

Can a system-generated ID make the survey anonymous?

Not by itself. If a mapping or other information can identify the person, hiding the name does not establish anonymity. Describe the actual confidentiality and follow-up arrangements accurately.

What if a household is not on the roster?

Use the approved new-registration process and unique-ID method. Flag uncertainty about whether it already exists; do not create or merge records solely to finish the form.

How do we handle a household that moves or splits?

A move may retain the same household record under your definition. A split may require new linked units. Define the rule, retain event dates and avoid assuming that an unchanged ID always represents an unchanged household.

What happens when someone declines future contact?

Stop future contact as required by the agreed process and record the status. Separately assess requests affecting historical data. Do not treat recontact preference, record linkage and deletion as the same action.

Can we import forms from Kobo or ODK?

Confirm the receiving product’s supported format and test the exact form. Do not assume calculations, repeat groups or offline behavior transfer unchanged. A documented data export may require a separate mapping process.

Is a manual matching review a failure?

No. A controlled review of uncertainty can protect data quality. The problem is an unsupported match presented as certain, or an unresolved record silently omitted from the report.

If your field collection includes attachments

Bring the reconciled batch and its source files to the document-evidence lesson. You will examine how attachments and transcripts retain their source, period and permissions when their contents are analyzed.

Lesson reviewed September 12, 2026. Partner P-024, H-014, H-015 and the visit records are fictional training examples.