Previous Next
Advanced offline feature
This article discusses advanced offline features. Advanced offline features are not part of a standard subscription. Get in touch to activate advanced offline functionality.

Data collection projects can be as simple as filling out a form once per respondent and submitting them to the server. In practice, running a survey is seldom that simple, due to difficulties in locating respondents, some refusing to respond, and the availability of others changing on an ad hoc basis, just to name a few common occurrences. It is helpful to have data about these events, as well as context from prior attempts to reach respondents, but basic data collection workflows don't provide forms with access to historical data.

More advanced workflows can be designed using server dataset publishing, filling this gap. Form data can be submitted to the server, which is then published to a server dataset. That data is then downloaded from the server by SurveyCTO Collect and then pre-loaded into forms. However, having a reliable Internet connection throughout a survey is rare, and while this does not affect your fundamental ability to collect data offline, it does mean that advanced workflows can't rely upon the server.

When you enable offline server dataset publishing, data publishing happens immediately using local copies of datasets even when offline, which has a wide range of use cases.

Sample advanced offline workflow features

The features that support more advanced longitudinal data collection and historical awareness of data collection are incredibly flexible. To help you understand what they can do, we've prepared a number of applied examples that you can test and experience first-hand as you learn. All of these solutions are adaptable and can be combined to build powerful solutions.

For these types of data collection workflows we recommend case management for its support for dividing and assigning lists of work to be done (e.g. survey samples) and tracking progress toward the completion of each unit of observation. When used correctly the case list can serve as an up-to-date list of work to be done that provides status information.

Consider and explore these examples:

  • Track the status of existing cases. As you attempt to reach each respondent in a survey sample, you can record both the current status of attempts to interview a respondent (e.g. "Not home", "Call back later"), as well as their final disposition (e.g. "Successfully interviewed", "Refused"). See our sample management workflow for an example.

  • Create one or more cases depending on whether you choose wide or long format publishing into your cases dataset (read more in Publishing form data into server datasets). This has a range of use cases, including creating child cases for individual respondents in a sample of households, adding replacement cases to ensure the same sample size, or drawing up samples in the field which could be redistributed using offline case transfers.

  • Close cases so that they no longer appear in the case list (e.g. upon successful interview, refusal, or when the respondent is declared unreachable). Do this by replacing the enumerator's assignment to a case in the list of cases with a bypass value like "closed" so that the case is hidden. Just keep in mind that case assignments can be set using the enumerators, users, and roles columns, so be sure that the bypass value updates the right column. See part 4 of our case management guide for instructions.

  • Update the list of forms assigned to a user, so that forms completed for a case can be removed, and newly relevant forms can be assigned to the case (according to your workflow). Do this by updating the formids column when publishing into the cases datasets. For an example of this, see our mobile case management workflow.

  • Update a case's label to keep track of the current status of the case. Do this by publishing a new value to replace the current one in the label column of the case list. Use functions like concat() to join dynamic and static content for a helpful, up-to-date case label.

  • Count the attempts to reach a respondent. Simply enter the number 1 into the calculation property of a calculate field and in your publishing configuration, use the Add option (rather than the default Replace option) to add 1 to an empty dataset field to count each time a form is finalized to update the case. Our basic CATI workflow shows how to track the number of phone call attempts.

  • Record new contact details (learned from relatives or neighbors). Up-to-date contact details can be invaluable for locating respondents. Our advanced CATI workflow shows additional contact details can be stored inside a case.

Note: Some of the above goals involve adding additional non-default columns to the cases dataset.

Organizing data collection across forms

Offline server dataset publishing is also helpful for breaking up data collection into smaller parts. Longer, more complicated form designs are also much more challenging to quality assure, and may not perform well on older, less powerful devices. You can divide up a data collection project over a number of forms, while still being able to link all forms to the same respondent and analyze that data together, as long as they share a common ID. This setup will be easier to test and should perform more reliably on older devices than one very long form.

When you use this kind of workflow, data collected in form A may be required in form B, which means the data from form A will need to be published to a server dataset so it can be pre-loaded by form B. With offline server dataset publishing, this workflow becomes seamless, with no need to wait for data publishing via the server, filling out one form right after the other even when Internet service is intermittent. Without this feature or a consistent Internet connection, a single form is required for data collection which can make for much longer, more complicated forms. Instead, you can use offline dataset publishing so your enumerators can easily fill out one form after the other.

For example, a list of household amenities recorded in an earlier survey module might be required later in an interview. That list can be published to a dataset, and then pre-loaded in a later form, eliminating the need to have both sections of the interview be part of the same form.

Previous Next