How to use the CATI starter kit without case management

This article is part of our guide to computer-assisted telephone interviewing (CATI). For context, start with part 1 of this guide. This article is accompanied by two sample forms, dataset definitions, and sample data. For the basic workflow sample click here; for the advanced one click here.

In our CATI starter kit guide, we have developed two sample case management workflows - basic and advanced - that might be suitable to your needs according to your project’s complexity. Their aim is to help you design the structure required for a phone interview, including choosing the respondent and phone number to call, rescheduling interviews, and counting the number of attempts. However, they assume that you will use case management. While there are advantages to using case management, it’s perfectly reasonable to choose not to use it. This article will provide you with an alternative to case management, and explain in detail the differences between a workflow with and without this feature.

If you want to jump straight to the discussion of the non-case management workflow, click here.

1. The case for case management

Case management organizes data collection around cases first, as opposed to forms. A case must be opened first, followed by a form associated with the case. A case can be anything you want (e.g. a phone survey respondents). The key advantage of case management is that it helps enumerators organize their attempts to contact each respondent in separate form submissions associated with that case, minimizing errors that may be caused by manually inputting respondent IDs (which case management takes care of). Not only that, data about the history of contact attempts can be stored inside the case, and even displayed in the cases list under Manage Cases. This can help the enumerator make informed decisions about whom to contact next, and when.

2. An alternative to case management

The good news is that displaying cases in a table is now possible inside a form design with our new table list field plug-in! This is how enumerators can select the respondent in our non-case management sample workflows. The main difference is the workflow for enumerators, who will open the form from the Fill Blank Form menu in the SurveyCTO Collect app (the standard non-case management procedure), and then inside the form, a list of pre-loaded records will be displayed in a table. This table works just like the table view for case management, but there is no need to enable or use the Manage Cases menu in this version of the CATI system.

The underlying data workflow described in part 2 of the CATI starter kit is much the same as the non-case management version of our proposed CATI workflow. It requires a regular connection to the internet so that form submissions can update records of interview attempts in the server dataset, before the local copy of the server dataset is updated.

For automated submissions and updates with the latest server dataset data, check out the early release version of SurveyCTO Collect for Android.

2.1. Choosing the right approach

To help you make an informed choice, keep in mind that the alternative proposed in this article works best when your CATI workflow involves one form. In contrast, case management can have many forms associated with a case, helping you to divide and stage interviews with respondents across sequential calls, if required. Case management also allows you to easily change case user assignments and form associations by publishing form data into the cases dataset, which is where case management's power and flexibility is useful.

Similar workflows that update the case list are possible using the table-list field plug-in. You could have more than one form, both using the same server dataset as source data for a table. It is also possible to combine different form designs into one, with different sections of the form being relevant based on data previously published to the server dataset. However, these designs can be complex to the point that case management would greatly simplify the form.

Even beyond the scope of this article, choose the case management feature for these reasons:

  • You want enumerators to pick the case first, as opposed to opening form, then finding the case inside the form.
  • Your data collection involves multiple forms.
  • Your data collection and form designs could be made simpler by having more rather than fewer forms.
  • Data collection across several forms should be done in particular order. The forms for each case will appear in an order of your choice, and you can train your enumerators to follow that order.
  • You want to take advantage of direct features that support case assignment, via usernames and user roles (learn more).

If the above statements are not true, in most cases, using the table-list field plug-in inside a form design can be a good option. Especially if your form design is short, there's no strict need to use case management.

We encourage you to read more about case management to make an informed choice.

3. Deploying the non-case management sample

Download a copy of each of the resources from one of the following Google Drive folders, depending on the workflow you want: basic or advanced sample form. Download copies to your local computer. In the case of the Google Sheet form definition, either save a copy to your Google Drive or download a copy (File > Download as > Microsoft Excel).

3.1 Form design

Deploy the form design first. Click on a "+" button on the left of the Design tab, then Upload form definition, pick the form design from either your computer or Google Drive, and upload.

3.2. Field plug-ins

Depending on the workflow, you’ll need to attach field plug-ins (.zip folders) to your form design using the Select one or more files to upload as form attachments option, as part of the form deployment process:

  1. If you've chosen the basic sample form, attach the table-list and call-phone-number field plug-ins.
  2. If you’ve chosen the advanced sample form, attach the table-list, call-phone-number, and launch-sms field plug-ins.

They can all be found in their respective resource folders.

3.3. Server dataset definition

Deploy the cases dataset definition second. Click on a "+" button on the left, then Add server dataset, and choose the New dataset from definition option. Pick and upload the "respondents.xml" or “respondents_advanced.xml” file for the basic and advanced workflows, respectively.

4. Solution discussion

Once you're clear on the reasons to choose a non-case management approach to CATI forms, explore what follows to understand the supplied non-case management sample forms.

While not using a “cases” dataset, the dynamics and requirements for a regular server dataset are very similar. Make sure you follow through all information explained in our CATI starter kit part 2. The only sections related to case management-only are: 4.1 The case list and 4.2. Viewing a case. In this example, enumerators will open and fill out the form via the Fill Blank Form menu.

4.1. Form definition

4.1.1. Unique identifier

Previously, the unique identifier was the caseid, calculated and stored based on the case selected via the “Manage Cases” menu. In this new approach, the id will be stored by selecting the respondent to be interviewed, using the table-list field plug-in:


This is a select_one field with an appearance expression that combines loading multiple choices from an external source with the parameters required by the field plug-in. The appearance should be something like this:

search('respondents') custom-table-list(delimiter='|',
headers='id, Name, Address, Attempts, Call back time, Last Status')

Let’s break this down for understanding:


This expression searches all unique values on the columns specified in the choice list, in the server dataset with ID “respondents”. The choice list for the field can look like this:

list_name value label
respondents id_key respondents_details

In this case, it will display all values from the column “respondents_details” (label) and store the corresponding value of the column “id” (value).

custom-table-list(delimiter='|',headers='id, Name, Address, Attempts, 
Call back time, Last Status')

In the dataset data, you may notice that the rows in the column “respondents_details” is a long string containing details about each respondent (e.g. name, address, etc.), delimited by the character “|”. The string represents the table rows, and the delimiter reflects the column separators. The custom-table-list() function will parse this content and construct the table with the specified column names.

4.1.2. Table content

The table content, i.e., the “respondents_details” value, comes from different calculate fields (e.g. “full_name”, “address”, “call_num”, etc.). While these are all stored and updated in the server dataset, we will need to combine them with a delimiter. For this, we have added an additional calculate field named “respondents_details” that uses the concat() function to concatenate all relevant fields:


This field is then published to the column “respondents_details” in the server dataset.

4.1.3. Closing a “case”

In the original version, we would make use of the case management’s user assignment to filter out cases from the table list view. By updating the column "users" to “Closed” (field: “pub_to_users”) the case would disappear from the “Manage Cases” menu, since there is no user with the username “Closed”. While we will still filter out respondents from the list here, the method will be different:

  1. Instead of the column “users”, we will use the column “now_complete” and ”now_closed” for the basic and advanced sample, respectively, to assess whether the case is completed or not.
  2. We will use the search type “matches” to display the cases that have a “now_complete”/”now_closed” value of ‘No’: 
search('respondents', 'matches', 'now_closed', 'No')


For more on the search() function, read the documentation, and see this webinar recording.

4.1.4. Assign users to cases

Optionally, as in the case management version, you can assign users to specific respondents using the same method explained in the last section. The search() function can take up to two filter parameters, so we can include both:

  1. A filter to only display the cases that are assigned to a specific user, and
  2. A filter to only display open cases.

This is an example of a search() expression that illustrates both levels of filtering:

search('respondents', 'matches', 'users', ${username}, 
'now_closed', 'No')

4.2. Server Dataset

The server dataset will change from a server dataset for cases to a regular one. In practice, this means that the mandatory columns for case management are no longer mandatory: id, label, formids, users, roles, sortby. In our samples, we kept two out of these 6 columns:

  • The id column will still be crucial for pre-loading and publishing of data. Still, we have renamed this column to id_key to be indexed for faster look-ups on your survey devices.
  • The users column will be required if you would like to assign users to cases.

Apart from the above, the publishing configuration will change in two ways:

  1. The column id_key should be mapped to the field “id” instead of “caseid”.
  2. The field mapping related to the columns label and sortby will be removed.
  3. The field “respondents_details” will be added to the field mapping, so that our table list plug-in can reflect all updates.

Do you have thoughts on this guide? We'd love to hear them! Feel free to fill out this feedback form.


Article is closed for comments.