Previous Next

When you have enumerators, interviewers, or observers filling out forms (i.e., when forms are not self-response web forms), it's important to know who it was who filled out any given form. Ideally, each filled-out form will include a unique enumerator ID, so that you can follow up with any questions, use statistical methods to detect enumerator effects, and track enumerator performance over time. SurveyCTO makes this process easy for both you and enumerators.

Here's how it works. First, you create an "enumerator" dataset on your server, to hold your list of enumerators, each with a unique ID. Once you have your enumerator dataset populated with your list of enumerators, you can attach it to any form and add an enumerator field to prompt the person filling out the form to identify themselves; they’ll be able to select themselves from a list, scan a QR code with their enumerator ID, manually enter their ID, or even add themselves as a new enumerator if needed. To save enumerators time and reduce identification mistakes, SurveyCTO will remember the enumerator’s identity from one form to the next, only prompting them to confirm that they are still the same person.

If your survey workflow uses case management, you can link cases to enumerators so that enumerators only see the cases assigned to them or their team. With such a configuration, enumerators identify themselves on the way into Manage Cases, and then their identity is only re-confirmed for each form they fill out.

See the sections below to learn more about how SurveyCTO helps you to manage and identify your enumerators.

Enumerators vs. users

When we talk about "users," as we do in the Managing users topic just above, we're talking about the logins people use to access SurveyCTO. When we talk about "enumerators," we're talking about the people who fill out forms. This raises the question: Aren't those the same thing?

The answer is: Yes and no. Every enumerator has to have a login, but the current login may or may not be the best way to identify the enumerator, for at least three reasons:

1. One login, several enumerators: While it is best practice to assign every enumerator their own individual login, sometimes there are too many enumerators coming and going, and managing separate logins for each is impractical. So several enumerators might share a single user account (perhaps a team login). Again, it's not best practice from an information security perspective, but it's common practice nonetheless.
2. One login, different enumerator: Even if you do have a separate login for every enumerator, one enumerator might log in on a mobile device, save their credentials, and then hand their device off to another enumerator to fill out one or more forms. So the current login at form-filling time may not correctly identify the actual person filling out the form.
3. One enumerator, several logins: A single enumerator might also use different logins to contribute to different projects over time, but all the same you'd like them to be identified in all of your data as a single enumerator with a single unique enumerator ID. That would help you to, for example, track enumerator identity and performance across projects.

As you'll see in the section just below, you can link enumerators with users so that, by default, the enumerator list only includes those enumerators most relevant for the current login. When you have many enumerators, this ability to link them with user accounts can streamline the process by which enumerators identify themselves when they fill out forms. You can even configure your enumerator fields to require a manager-level override code to choose an enumerator identity at odds with the current login, if you wish to control who can select which enumerator identities.

Finally, it's best practice to also capture the current username with each form, so you can have (a) the explicitly-confirmed enumerator identity and (b) the user login identity, both available in your data.

Enumerator datasets: Managing your list of enumerators

Your list of enumerators lives in an enumerator dataset, which is a special kind of server dataset with specific fields and configuration. To create one, navigate to the Design tab, scroll down to the Your forms and datasets section, click + and then Add server dataset, and switch to the New dataset for enumerators tab. Each time you create a new enumerator dataset you will specify a title and ID for the dataset, set an enumerator ID format, and optionally add some initial enumerators.

  Create as many enumerator datasets as you need

Many SurveyCTO users will be happy to use a single enumerator dataset for all of their forms. However, if you prefer to keep your enumerator lists separate for different projects or teams, you can create as many different enumerator datasets as you wish.

The ID format is configurable as a convenience, so that SurveyCTO can offer new enumerator IDs when enumerators are created — but whoever is adding an enumerator will always be able to specify whatever ID they prefer. The default ID format is just a six-digit number, but you can make it a different length, add a fixed prefix or suffix, and allow capital letters for alphanumeric IDs.

In your enumerator dataset, each enumerator is a row with columns for each of the following details:

1. id. This is the unique ID that identifies each enumerator. It can be in any format, but each enumerator must have a unique value, and your enumerator list should only include a single row for each unique id.

2. name. This is the enumerator's display name. It can be in any format, but each enumerator must have a unique name. While both the id and name must be unique values, the name should be something the enumerator will be able to read and recognize immediately as their own.

3. users (optional). If this column is absent or blank for a given enumerator, every user will see that enumerator in the default list of enumerators shown by the enumerator field. To only include the enumerator in the default list for one or more specific users, put a comma-separated list of those users in this column. (See just above for more on users vs. enumerators.)

   Even when you use the users column to control which enumerators are shown to which users, note that all users can still see and select any enumerator, by default, by choosing Show other enumerators or by entering or scanning an ID that's not listed. To prevent users from seeing or identifying themselves as an enumerator at odds with their current login, use the "other-user-code(xyz)" option in your enumerator field: that will require your specified code be entered before listing, entering, or scanning an identity in the Show other enumerators list.

You can build your enumerator list in a .csv file, an Excel file, or a Google Sheets document, and upload that list into your enumerator dataset; the bolded names above are exactly what should appear in your spreadsheet's first row (as the names of the columns). You can also edit your enumerator dataset directly on the Design tab: just scroll down to the Your forms and datasets section, find your dataset, and click Edit.

Beyond those three columns, you're free to extend an enumerator dataset to include whatever additional fields you'd like. Those additional fields would just be yours to manage, either manually (by uploading new data or editing the dataset on the Design tab) or automatically (by publishing form data directly into the dataset). See Advanced publishing with datasets and Pre-loading data into a form for more about your options for working with server datasets. Just one important note on publishing into enumerator datasets:

  Publishing into enumerator datasets: form field to identify unique records

When you publish into an enumerator dataset, you will always want to use the id column as the unique identifier to merge on. However, the enumerator field stores the enumerator name and ID together in a single value (formatted with the name followed by the ID in parentheses, as in "John Doe (ENID0794)"). To be able to publish into the enumerator dataset, you'll need to use a calculate field that calls the enumerator-id() function, and then use that ID (without the name) as the form field to identify unique records. (For convenience, a separate calculate field for the ID is automatically added for you when you add an enumerator field in the online form designer.)

Enumerator fields: Identifying enumerators — and adding them when needed

  New feature

The enumerator field type is a new feature that was added to SurveyCTO Collect in v2.72. To make sure the field appears and functions properly in the Collect app, you can enable the enforce minimum app version setting in your server console. See the topic on managing device security for more information. Click here for instructions on installing and updating Collect.

Once you've created your enumerator dataset, you can attach it to a form and add an enumerator field to identify the enumerator filling out the form.

When someone arrives at the enumerator field in your form, they will be able to identify themselves by picking themselves from the list of enumerators, entering their unique enumerator ID, or scanning a QR code (in the SurveyCTO Collect mobile app). Once an enumerator has identified themselves using an enumerator field, SurveyCTO will remember that identity within the workspace (in the mobile app) or browser (in web forms) until they log out or explicitly switch enumerators, only asking them to re-confirm their identity at each enumerator field.

If an enumerator finds themselves at an enumerator field, but they are not yet in the enumerator dataset and therefore cannot select, enter, or scan their ID, they can click the Add new enumerator option at the bottom of the field. This will allow them to add themselves as a new enumerator, and SurveyCTO will suggest a new randomly-generated enumerator ID based on the default format specified by your enumerator dataset. Once the form submission containing the new enumerator is received on the server (and approved, if using the review and correction workflow), the new enumerator will be automatically published into the enumerator dataset.

If you want to restrict who can add new enumerators in this way, you can use the "add-new-code(xyz)" option in the enumerator field. Doing so will require the user to correctly enter the code you specify before being allowed to add a new enumerator.

See the documentation for the enumerator field type for more details.

  All new enumerator IDs publish into enumerator dataset

Anytime a submission comes in with an enumerator field value, SurveyCTO will check to see if the enumerator ID is already in the attached enumerator dataset. If not, a new row will automatically publish into the dataset with the enumerator's ID and name, as found in the field value. In general, this happens when new enumerators are added via the Add new enumerator option, but it can happen also in other cases. For example: you could delete an enumerator from your enumerator dataset, but then a new submission comes in for that enumerator, and so it gets re-added to your dataset; you could change an enumerator's ID in the enumerator dataset, but then a new submission comes in with the old ID and it gets re-added to your dataset; or, you could edit an incoming enumerator ID in the review and correction workflow and trigger the addition of a new enumerator on approval. Finally, note that SurveyCTO will automatically add text to newly-publishing enumerator names as-needed to avoid conflicts with existing rows.

Case management: Linking cases to enumerators

If your workflow uses case management, you can link cases to enumerators so that the Manage Cases list will include only cases relevant for the current enumerator. Here's how:

1. Link your cases dataset to the appropriate enumerator dataset. You can do this on the Design tab: scroll down to the Your forms and datasets section, find your cases dataset, click Settings, choose the appropriate enumerator dataset, and save.
2. For each case, include a comma-separated list of enumerator IDs in the enumerators column (just the way you might include lists of users in the users column). You can do this by editing your cases dataset directly on the Design tab: scroll down to the Your forms and datasets section, find your cases dataset, and click Edit. (If your cases dataset doesn't have an enumerators column, you'll need to add it. Do this by downloading your cases dataset, adding a new column with "enumerators" in the first row, and then uploading back into your cases dataset.)

Once your cases and enumerator datasets are linked and at least one case is linked to at least one enumerator ID, the Manage Cases interface will begin requiring that enumerators identify themselves, so that the appropriate cases can be listed. Cases with one or more enumerator IDs listed in their enumerators column will appear only for those enumerators, provided that the users and roles columns aren't used to further restrict who can see which cases. See the full help topic on case management for details about how you can restrict cases to enumerators, users, and/or user roles. Cases without anything in their enumerators, users, and roles columns will appear to everyone.

To streamline enumerator identification, the current enumerator's identity is shared between the case-management and form-filling interfaces: after selecting an enumerator in the Manage Cases screen, all forms in the workspace (in the mobile app) or browser (in web forms) will recognize that enumerator selection until they log out or explicitly switch enumerators; likewise, after selecting an enumerator within a form, that enumerator will automatically be selected in the Manage Cases screen.

Finally, note that there is no Add new enumerator option available when enumerators identify themselves in the Manage Cases interface. If a new enumerator wants to fill out a form for a case, they will have to first identify themselves as an existing enumerator in order to see the case, then, in the form itself, they can add themselves as a new enumerator.

Previous Next