Prepare field forms, preserve visit IDs and verify uploads. A practical protocol for collecting offline without losing record context.
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.
This lesson continues Connected Data Intelligence. You have mapped the records and learned how to version changing questions. Now test whether that design survives a field visit, a device change and a delayed upload. Your deliverable is a short field protocol and a reconciled test batch.
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.
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.
| Change | What to test |
|---|---|
| A different device | The next fieldworker can select the correct authorized subject; an upload arriving late retains its visit date. |
| A different fieldworker | The protocol explains how to confirm the subject without relying on a colleague’s memory. |
| A long gap | Changed contact details do not automatically create a new person; household changes receive an explicit rule. |
| A lost card or forgotten code | A permitted recovery process exists; uncertain identity is flagged rather than guessed. |
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.
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.
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.
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. This is why the lesson should not claim that field tools lack continuing records; the useful evaluation is whether the configured workflow handles your exact relationships and conflicts.
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.
Continue the fictional Partner P-024 example. 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.
| Record | Subject and event | Expected result |
|---|---|---|
| V-101 | H-014 · September 2 · device A | One visit, even if uploaded after V-102 |
| V-102 | H-014 · September 9 · device B | A second visit linked to the same household |
| V-103 | H-015 · September 9 · device A | A separate household and visit |
| Retry of V-102 | Same submission attempted again | Recognized as a retry; not a fourth visit |
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Start with data your teams struggle to bring together. Agree shared definitions, keep each source identifiable, and decide who can see what before asking AI for an answer.
Explore Connected Data Intelligence →
