CommCareHQ allows you to define Lookup Tables that can be used in your forms for information that changes over the lifetime of your application, or is different for each user.   Here are some examples of potential functionality that can be added with lookup tables:

1. Filtered Choices: Filtering the choices of a Single or Multiple Answer question based on the answer to the previous question.  For example, if the user chooses State in one question, the next question will only show the Districts in that state. This is useful for drilling down into different locations.

2. User Specific Choices: Providing a set of choices for a question that are specific to the logged in user.  For example, in a referral form, you may only want to show the list of referral sites that a particular user is responsible for. 

3. Randomized Questions/Messages:  Choosing a random question or message for a user from larger set.  For example, you can define a bank of knowledge questions in a lookup table and randomly choose to ask or show one of those each time a form is opened. 

Note 1: This functionality depends on having a user logged in and hence won't work in demo mode. 

Note 2: To update lookup tables on the phone over time, you need to turn on "Two Way Sync". 

Need help setting up your first look-up table in Excel? Download this sample to get started.  

Creating and Updating Lookup Tables

What is a lookup table?

Lookup tables are used in applications to provide data that is not directly stored in the application and may change over time. For example, you can use them for a list of villages that changes over the time of your project. They also allow you to assign certain data (ex. villages) to certain users. They are particularly helpful for grouping related information like defining geographical locations. 📖Learn more about Referencing Locations in Applications.

Define a Table

A table consists of fields which defines the information to be stored. A project can have multiple tables defined and multiple fields can be defined for a given table. Note: Hierarchal data is best managed with a table for each variable (ex: state, district, block, and outlet).

1. Login to CommCare HQ.

2. Click the Data link on the Dashboard.

Open

3. In the Lookup Tables section, click Manage Tables. 

Open

4. Click the Add Table button.

5. Specify the Table ID (unique name that describes the table's contents)
Note: Special characters and spaces cannot be included in a Table ID.

6. Include Fields (information to be stored in a table) by clicking the Add Field button.

7. Click Save when finished.

Note: The Visible to all users? selection determines whether a table is public or assigned to individual users. This is especially helpful when users should only see those items that are related to them. Applications deployed in multiple languages require more than one Field for a given property (i.e., state name, state abbreviation) 📖Learn more in this section.

Viewing Table Data

After a table(s) is created, the view tables option can be used to see its data.

1.. Login to CommCare HQ.

2.. Click the Data link on the Dashboard.

3. In the Lookup Tables section, click View Tables.

Note: Tables can also be viewed in the Manage Tables window by clicking View Table next to the table ID of interest.

Downloading Table

Once a table is created, it can be downloaded for bulk editing. New tables can be created or existing tables updated by uploading Microsoft Excel files.

1. Navigate to the Manage Tables window.

2. Identify the lookup table of interest.

3. From the Manage Tables section, click the Include in Download checkbox next to each table of interest.
Note: The all or none buttons can be used to select or deselect multiple tables.

4. Click the Download Lookup Tables button. Download time will vary by connection speed.

Note: The downloaded Microsoft Excel file includes a sheet titled Types, a sheet for each table with collected data, user ID columns, and Delete (Y/N) columns. The Types sheet is necessary when defining advanced lookup tables. 📖 Learn more in this section.

Upload Table

1. Navigate to the Manage Tables window.

2. From the Upload Lookup Tables section, click Choose File and select the desired Microsoft Excel file.

3. From the Upload Lookup Tables section, click the Replace Existing Tables checkbox.
Note: The Replace Existing Tables option will replace any existing tables with new data from the uploaded Microsoft Excel file. If not selected, existing rows will be updated with data from the Excel file, and any new rows from the file will be added to the lookup table.

4. Click the Upload Tables button.

Editing Table Data in MS Excel

When lookup tables are downloaded for editing in MS Excel, the file includes a sheet titled Types along with a sheet for each table with collected data to include a UID and Delete (Y/N) columns. The Types sheet is necessary when defining advanced lookup tables. 📖 Learn more in this section.

Example: "District" table download

Types sheet

District (table) sheet

Note: If a table requires rows assigned to users (i.e., user 1, group 1), these columns should be added manually. 📖 Learn more about at https://dimagi.atlassian.net/wiki/x/1SrKfw.

Splitting Lookup Tables

Tables can become very large and degrade application performance when deployed to mobile devices. This issue can be avoided by splitting large tables which is especially helpful for location-based lookup tables that will need to reorganize.

1. Complete steps 1-3 from "To download tables"

2. Open the download file ("Sheet 1" in this example).

3. Create a second sheet in MS Excel ("Sheet 2" in this example).

4. Copy and paste all of the fields from the Types tab of "Sheet 1" into "Sheet 2."

5. Rename the "Sheet 2" tab.

6. From the "Sheet 2" tab, change the table_id to a title of choice (ex: "hypertension_2").

7. In "Sheet 1", copy the table headers (i.e., UID, Delete, etc.) in row 1 from the tab that contains the lookup table name ("hypertension" in this example).

8. In "Sheet 2", create a new tab and assign a name of choice for the lookup table.

9. Copy the headers into row 1 of "hypertension_2" (or the name you chose in step 6).

10. Transfer the cells from "Sheet 1" that should be included "Sheet 2."

11. Complete steps 1-2 of "To upload data."

Note: After all steps above have been completed, the lookup table references should be updated or a second question can be added to a Form to reference the new lookup table instead.
The result is a second lookup table that contains file that was split. Below is an example.

Lookup Table Tips & Tricks

Example: In-Form Lookup Table Querying

Lookup table data can be referenced in forms in ways other than as potential selection choices. This provides a quick example to show you how.

Add the sample table

Download the attached Excel File and upload the file into your project space.

Afterwards you should have the following lookup table available:

Copy the example form

Copy the following text with your web browser and paste it into the tree pane of a CommCare HQ form builder form:

Afterwards, you should see these questions added into your form:

Test It Out

You will need to be logged in as a mobile user to test the form, either on a mobile phone or by using the Login As feature in live preview to choose a mobile user.

Once you've loaded the form, you should be able to choose a filter, and see an up-to-date count of how many items from the lookup table match the filter.

Understand

The lookup table querying is done inside of the #form/count Hidden Value calculation:

^{count(instance('item-list:fruit')/fruit_list/fruit[type = #form/fruit_counter/what_kinds_of_fruit_do_you_want_to_count])}

This shows how the lookup table can be queried with xpath syntax by starting expressions with the following root, with filters applied for additional logic

^{instance('item-list:fruit')/fruit_list/fruit}

For example, to print a list of the names of all citrus fruits instead, you could use the expression

^{join(" ", instance('item-list:fruit')/fruit_list/fruit[type = 'citrus']/name)}

Experiment

Once you've loaded the form, you can use the Data Preview XPath Evaluator to experiment with different expressions, and see the data live. 

This tool is especially helpful for experimenting with lookup table queries because it can display for you the intermediate outputs of the filters, which can be a big help when debugging more complex expressions.

NOTE - In order for you to be able to reference a lookup table from this tool, your form needs to already contain at least one reference to the lookup table in another expression (calculation, display condition, selection choices, etc) for the form to be connected to the table. You can see the lookup tables connected to your current form by typing "instance" into the tool and seeing what autocompletes.

Advanced: Indexing Lookup Tables (Larger Lookup Tables

Indexes are designed to solve a specific problem: references to a large lookup table are slowing down your application. For example, suppose you are using a lookup table to Setup a Question with Filtered Choices. Your lookup table, health_centers_by_region, has the following fields:

• district_id

• health_center_id

• mnch_services_available

and you have a hidden value that contains the calculation:

• count(instance('health_centers_by_region')/health_centers_by_region_list/health_centers_by_region[mnch_services_available="yes"][district_id = /data/district_id])

If this table is large enough that this filter is slowing down performance in your form, you may be able to alleviate this by adding an index to district_id and moving the indexed field to the front of your filter, so that:

• [mnch_services_available="yes"][district_id = /data/district_id]

becomes:

• [district_id = /data/district_id][mnch_services_available="yes"]

Definitions

• A query refers to any XPath expression that retrieves data from a lookup table. This includes filters on lookup table questions, as well as any calculations that contain something of the form: instance('table_name')/table_name_list/table_name[filter_1][filter_2]...[filter_n]

• The cardinality of a field in a lookup table is how many unique values of that property are represented. The more unique values are represented in the table, the higher that field's cardinality. For example, an ID field for which each value only appears once in the lookup table has very high cardinality, while a True/False field has only two possible values over the entire lookup table, so has very low cardinality.

What is an Index?

An index is a data structure that helps make certain XPath expressions that reference a lookup table more efficient. When you index a field in a lookup table, you can improve the speed of expressions on that particular field. The following scenarios highlight the difference between querying a field that is indexed, compared to querying an unindexed field:

• Example Query: instance('state')/state_list/state[name="Bihar"]/population

• name is not indexed: The query evaluator loads a row of the state table, checks to see whether its name property is equal to "Bihar," returns the population field if so. Repeat for every single row of the table.

• name is indexed: The query evaluator checks the index to find the exact location in the table of all elements where name is equal to "Bihar," loads all matching elements in one operation, returns their population fields.

When Should I Create an Index on my Lookup Table?

Most lookup tables will not need to be indexed. If you think you might need to index one or more fields of a lookup table, ask yourself:

• Is my lookup table very large (many hundreds of records or more)?

• Do I query the same few fields over and over again in my app?

• Have I noticed slow app performance related to these queries?

• Do any of these fields have a high cardinality?

If you answered "yes" to all of the above questions, it might be worth adding an index for one or more fields in your lookup table. If you're not sure whether a particular query is slowing down your app, try the following exercise:

1. Create a form consisting of 3 questions:

   1. label1

   2. lookup_query

   3. label2

2. label1 and label2 are label questions, and can contain whatever you want.

3. lookup_query is a calculation question, whose calculate condition is set to the exact query that you believe might be causing the slowdown.

   1. If your query contains references to question_ids in the form whose values are dynamically generated, replace these with a static representative value. For example, in the query from the Overview, we can select an arbitrary district_id (e.g. "123") to use in place of /data/district_id.

   2. If you are concerned about a filter on a multiple choice question, your query is going to be: instance('table_name')/table_name_list/table_name[your filter here], where table_name is the name of the lookup table. In the example from the overview, our query would be: instance('health_centers_by_region')/health_centers_by_region_list/health_centers_by_region[district_id="123"][mnch_services_available="yes"]

Indexing Tables Used in Multiple Choice Lookup Table Questions

If you are populating a multiple choice or checkbox question from a lookup table, and are still experiencing performance issues after indexing any appropriate columns from the filter, try adding indexes for the Value Field and the Display Text Field.

How Do I Add an Index?

Suppose you have a lookup table health_centers_by_region with the following fields (this is the same table from the Overview above):

• district_id

• health_center_id

• mnch_services_available

As part of your workflow, a mobile worker often needs to select a health center in a certain region that has MNCH services available. There are thousands of health centers spread over hundreds of districts, and you've noticed that a query that appears throughout the app is taking a long time:

• instance('health_centers_by_region')/health_centers_by_region_list/health_centers_by_region[mnch_services_available = "yes"][region_id=/data/region_id]

Since district_id has hundreds of values represented, it has a high enough cardinality to warrant an index. mnch_services_available will only ever be set to "yes" or "no." Since the cardinality for this field is low, the benefits of indexing the field would be minimal compared to the extra space it would take up on the phone, so it should not be indexed.

Before adding an index to the lookup table, please refamiliarize yourself with the process of creating and updating lookup tables, specifically downloading or uploading tables for editing.

When you're ready to add an index, follow these steps:

1. Download the lookup table following the steps in the previously linked documentation.

2. Open the file and navigate to the types tab. It should look something like this: 

3. Add a column with header "field 1 : is_indexed?" and mark the column as "yes" for the field and table that you want to index:

Once the index has been added, you will need to rewrite your query so that the indexed field or fields appear at the beginning of the string of filters. Since region_id is indexed and mnch_services_available is not, our example becomes:

• instance('health_centers_by_region')/health_centers_by_region_list/health_centers_by_region[region_id=/data/region_id][mnch_services_available = "yes"]

See the next section for details.

Query Optimization

When writing XPath queries on an indexed lookup table (or on any indexed fixture, such as casedb), it is important to write your query such that all filters on indexed properties are evaluated BEFORE other filters. For example, say you have a lookup table health_centers_by_region with the following fields:

• region_id (indexed)

• health_center_id

• mnch_services_available

If we want a query to return all health centers in region 123 where MNCH services are available, we would write:

• instance('health_centers_by_region')/health_centers_by_region_list/health_centers_by_region[region_id="123"][mnch_services_available = "yes"]

With this query, the XPath query evaluator will first use an efficient key lookup to filter on the indexed field (region_id), before performing single lookups on each of the results to check whether mnch_services_available = "yes" for each one.

The following documents go into much further technical detail on XPath evaluation and optimization:

• Primer: XPath Query Evaluation

• Performance: XPath Query Evaluation

Limitations

Complex Queries

Currently, only the most basic XPath queries will leverage lookup table indexing. For example: value = 1 will use the indexing, but value < 2 will not. In addition, composite queries using and or or will not leverage the indexes.

Lookup Tables with Multiple Languages

When indexing a lookup table with multiple languages, you can only index fields that do not have translations. Indexing columns with attributes is unsupported.

Setup a Form to Display a Random Question from Lookup Table

This section will walk through an example of setting up a form that will display a random yes/no question from a lookup table.  This is useful for asking randomized questions for doing knowledge assessment, or to send random behavior change communication out (for example, using CommCare Messaging).  

First set up the following table using the section on creating tables. Set up the table so that they are available for all mobile workers in the project.  

random_question

This table has two categories of questions - this corresponds to two different random questions that we will include in our form. 

Including Lookup Table Information in the Form

Once we've defined a lookup table, we need to reference it in our form.  This is done by adding an "instance" line that references the name of the table.  You can place this above any existing instance tags in your form.  

You can choose any word for the id="__" portion.  This is how you'll reference your lookup table in the rest of the form.  For the src="jr://fixture/item-list:____" section, you must specify the Table ID that you created the table with.  

Selecting a Random Question

First, lets add two select question to the form  for each of our random questions.  

Next ,we need to add 3 hidden values per random question we want to ask. These are used for selecting a random question, storing the ID of the selected random question and storing the actual question text of the random question.  Add the following hidden values as shown below.

Now we'll add calculate conditions to each of the hidden values, starting with those for the planting random question.  

In the planting_question_num hidden value, add the following calculate condition: 

This calculation looks a bit complicated, but it basically checks the number of questions in the fertilizer category, and randomly picks a number between 1 and the number of questions.   

Note: You may get a notice saying that the expression was too complex to validate.  You can just hit "Ok" as this is expected when using lookup tables.  

In the planting_question_id hidden value, add the following calculate condition:

This calculation makes sure that a planting_question_num has been calculated, then stores the question_id for the randomly chosen question. 

In the planting_question_text hidden value, add the following calculate condition:

This calculation is similar to the previous one, but instead of storing the code, it stores the actual question text to be displayed. 

Next, we will change the label for the the "Planting Random Question" select question to just display the text of the selected question, using an <output value="..." /> statement.  Change the label as is shown below. 

You can now setup similar calculations and labels for fertilizer calculations and question.  You will just need to change the question_category to "fertilizer" instead of planting in any calculations.   

Testing an application with Lookup Tables

In order to test the conditional select options and other logic works in the application, you must sign on as a mobile user and submit 'real' data to the server. 

1. Generic User: Create a generic user called "dimagi" or "demo" and update the fixture specifically for this user - populating all the conditional select options with the same 'dimagi' or 'demo'. As long as the partner is aware of the use case, they will be able to filter out this user in reports. During training, mobile users will sign onto CommCare and submit live 'practice' data. Work with the partner to specify a date where all data submitted to CommCare HQ is considered actual data for program purposes. This should be made clear to the FLWs and to the data analyst/M&E officer.

2. Training Application: Copy the final application - remove the conditional select options from the application. This app can be used during training as a training application and the users can enter data in demo mode.

3. No SIM: If the partner has not secured SIM cards for the phones prior to training, install CommCare on all the phones. Use one SIM card to restore the user or practice user ('dimagi' or 'demo') to all phones. The phone will update according to the latest fixture item list on HQ. Remove the SIM. The conditional select options will work on the phones and the data will not be submitted to the CommCare HQ.

Setup a Question with Filtered Choices

This page will walk through an example of setting up a form that both displays conditional options in lists (list of districts from chosen state) and has options that are specific to each user. 

First setup the following two tables using the Creating and Updating Lookup Tables section.  You can use whichever mobile workers or groups that you have in your project.  

state: 

district: 

Our sample creates two tables (state and district).  The district table has three fields (id, name and state_id).  The state_id will be used to filter the list of districts based on the selected state.   The following image shows our final setup.   

Create a Multiple Choice/Checkbox Question Based on a Lookup Table

NOTE: Lookup tables referenced in Multiple Choice or Checkbox questions should not have values with spaces in them. This can cause data issues in your app. Please define the values in the lookup tables without spaces.

To create a multiple choice or checkbox question based on a lookup table, first add the question to your form.

In our example, we'll add two multiple choice lookup table questions, "state" and "district".

Now go to "Lookup Table Data" and select the correct lookup table and value and label fields. When inputting the value and labels an autocomplete widget will show you valid options for these fields.  

If you were to test this application, you'd see the first question displays a list of all states and the second question displays a list of all districts (irrespective of the selected state).  To filter the district list, we need to add a filter condition to the choices. 

Filtering the Choices

To filter the set of choices, you can use the 'Filter Option' under 'Lookup Table Data' (similar to the expressions used when defining Display Logic or Calculations in your form).  In our example, we'll filter the District item list based on the selected state.  Our district table contains a field called "state_id".  The values in this match the value specified for the state question.

The left option will show an autocomplete widget to help you pick a lookup table attribute and the right option will allow you to drag a question from the question tree. 

Loading a lookup table value into a hidden value instead of a multiple choice/checkbox question

Sometimes you'll want to pull information from a lookup table into a hidden value. For example, from the example above, you want to save another case property called "project_name" and after the user selects a district, you already know which project it falls under. You create a hidden value question under the district question and name it "project_name". Then you create the following lookup table:

project:

In the hidden value you'll enter the following calculation: instance('item-list:project')/project_list/project[id = /data/district ]/project_name. Depending on what the user chooses for district, the value for "project_name" will be either 'nutrition' or 'agriculture'. From the formula, the first 3 'project' refers to the lookup table name. 'id' is the value from the column in the lookup table that is matched with the question 'district', which has '/data/district' path in the form. The last part of the formula is 'project_name' and will be the value taken from the same named lookup table column and loaded into the hidden value. 

How to enter your own value using an 'other' option

There might be times where you want to give the option to enter a location or value that might not be in the lookup table. You can do so by adding an 'other' option to your district table and a text question to your form that will only be displayed when the 'other' option is selected. The following steps will show you how to do so.

Using the example above, we want to allow the user to enter a district that is not in the lookup table. To do so, you can add an ‘other’ field to the district lookup table:

You then proceed to create the form like you did above:

Once the locations are set up, you need to add another filter to the lookup table question in the form. This filter will be based on the district ID, so the first field should be set to ‘id’. The second field should be set to ‘is equal’. And the third field should be set to ‘other’. We also want this option to occur only when ‘other’ is selected, so we also need to change the ‘Result is’ field to be ‘True when ANY of the expressions are true.” Be sure to save the expression once you are done!

After saving the new expression and returning to the question properties page, you should see the full expression:

Now you just need to add another text question to the form that will be displayed only when ‘other’ is selected:

Now when your users select ‘other' for the district, they will be able to proceed to another question that will allow them to enter the district name. 

Testing an application with lookup tables

In order to test the filtered choices and other logic works in the application, you must sign on as a mobile user and submit 'real' data to the server.  If you see an error when opening the form that states "Could not find an appropriate fixture for src: jr://fixture/item-list:table_name" you have not properly setup your lookup tables. 

1. Sync your application. Some users have reported this error with large lookup tables that have not properly downloaded which choosing "Update Commcare" from the menu. Run the sync to ensure all assets are properly downloaded to the device

2. Make sure that the current user has lookup table rows assigned to them (https://dimagi.atlassian.net/wiki/spaces/commcarepublic/pages/2143955074/Lookup+Tables#Creating-and-Updating-Lookup-Tables).

3. Alternatively, setup your lookup table so that it is available for all users (For the lookup table, set it up so that it is "Visible to All Users" by clicking Edit Type). 

4. Once you've done this, make sure you've synced your phone. 

If you run into issues testing your app with lookup tables, try to Clear user data. After you sync your phone if the lookup table still is not working, you may need to clear user data and log-in again. To do this, go to the login screen and click on Settings. After the Settings screen shows up, click the menu button, and select the first option, "Clear User Data." This will clear the username and force you to re-enter login credentials. Once you log in again, the new or edited table should be accessible to your user.

Training an application with lookup tables

1. Generic User: Create a generic user called "dimagi" or "demo" and update the table specifically for this user - populating all the conditional select options with the same 'dimagi' or 'demo'. As long as the partner is aware of the use case, they will be able to filter out this user in reports. During training, mobile users will sign onto CommCare and submit live 'practice' data. Work with the partner to specify a date where all data submitted to CommCare HQ is considered actual data for program purposes. This should be made clear to the FLWs and to the data analyst/M&E officer.

2. Training Application: Copy the final application - remove the conditional select options from the application. This app can be used during training as a training application and the users can enter data in demo mode.

3. No SIM: If the partner has not secured SIM cards for the phones prior to training, install CommCare on all the phones. Use one SIM card to restore the user or practice user ('dimagi' or 'demo') to all phones. The phone will update according to the latest lookup table on HQ. Remove the SIM. The conditional select options will work on the phones and the data will not be submitted to the CommCare HQ.

Factors contributing to form's performance using LookUp Table : 

In many cases, your Lookup table may scale up to a point where it starts to make your form inefficient for user to use. Lookup tables tend to deteriorate the user experience in such scenarios. 

• Number of rows in a lookup table plays a major role in deciding the form's performance while user navigates to the question using that Lookup Table.

• Performace of form loading as well as form navigation is independent of size of data in each column of the table. It is also independent of number of Lookup Table type questions have been setup in the form. 

• You can improve the performance of by indexing a lookup table or using other techniques like using Combo Box for appearance attribute of single-select type lookup table.

Using Lookup Tables with Multiple Languages

For larger applications, you may need to have a lookup table that supports multiple languages.  Based on the language selected for the application, CommCare can be setup to get the correct language information from the table.  

Defining a Lookup Table that Support Multiple Languages

Please review the Creating and Updating Lookup Tables section to understand the basics of defining lookup tables.  Unfortunately, the current interface cannot be used to completely define a table that supports multiple languages.  Instead, we can upload an Excel document that sets up the table for us. 

1. Define a basic table that includes the information you'd like to store.  Here is an example of a table that stores States. Note: I've set this table up so that its visible to all users (for simplicity).

2. Download the table from CommCareHQ to add language information. 

3. Modify the types sheet to identify which columns will have multiple languages.  This is done by adding an extra property on the field that will indicate the language. This is highlighted in Red below. 

4. Modify the state sheet to add the list of states with each language.  We'll also need to modify this sheet's columns to include the additional language information.  You will need to add columns for each language supported.  The example below includes two languages, but you can add additional columns titled name: lang X and field: name X for more languages.  

In the lang column, specify the language code used in CommCareHQ for the language.  You can find this by reviewing https://dimagi.atlassian.net/wiki/x/njTKfw.  In this example, I've used English and Hindi.   (Note: For new rows, you can ignore the UID and Delete(Y/N) columns).  

5. Upload the updated Excel file to CommCareHQ.  You can check "Replace Existing Tables" to replace any existing data for this table on CommCareHQ.  

6. You can review the uploaded data by clicking the View Table link next to the table on the page.  

Using Multiple Languages with Multiple Choice/Checkbox Questions

1. First we need to setup a label that contains the language codes that you want to use in your app.  In your form, add a label with the question ID of lang-code and label text that matches the language code for each language.  We'll also set a Display Condition of 1=2 on this to ensure that it doesn't appear in the form.  This label will be used to determine which language to display, based on what language is chosen. 

2. Now add a single or multiple answer lookup table question question to the form.

3. Choose the Lookup Table Data item.

a. Set the lookup table to the lookup table you uploaded (ex. state)

b. Set the value field to the column in your table you want to store (ex. id)

c. Set the display text field to the following: name[@lang = jr:itext('lang-code-label')] . You can replace name with the column that contains multiple languages. 

4. Update and Save your form.  Now the list of options should change their label based on what language is chosen for the application.  However, the data stored will remain the same.

Testing an application with lookup tables

In order to test the filtered choices and other logic works in the application, you must sign on as a mobile user and submit 'real' data to the server.  If you see an error when opening the form that states "Could not find an appropriate fixture for src: jr://fixture/item-list:table_name" you have not properly setup your lookup tables (make sure you did tap the blue button in the app menu "sync with server" before going into the form as this can give the same error message. When you sync, the updated lookup table(s) will be downloaded to your device). 

1. Sync your application. Some users have reported this error with large lookup tables that have not properly downloaded which choosing "Update Commcare" from the menu. Run the sync to ensure all assets are properly downloaded to the device

2. Make sure that the current user has lookup table rows assigned to them ().

3. Alternatively, setup your lookup table so that it is available for all users (For the lookup table, set it up so that it is "Visible to All Users" by clicking Edit Type). 

4. Once you've done this, make sure you've synced your phone. 

If you run into issues testing your app with lookup tables, try to clear user data. After you sync your phone if the lookup table still is not working, you may need to clear user data and log-in again. To do this, go to the login screen and click on Settings. After the Settings screen shows up, click the menu button, and select the first option, "Clear User Data." This will clear the username and force you to re-enter login credentials. Once you log in again, the new or edited table should be accessible to your user.

Training an application with lookup tables

1. Generic User: Create a generic user called "dimagi" or "demo" and update the table specifically for this user - populating all the conditional select options with the same 'dimagi' or 'demo'. As long as the partner is aware of the use case, they will be able to filter out this user in reports. During training, mobile users will sign onto CommCare and submit live 'practice' data. Work with the partner to specify a date where all data submitted to CommCare HQ is considered actual data for program purposes. This should be made clear to the FLWs and to the data analyst/M&E officer.

2. Training Application: Copy the final application - remove the conditional select options from the application. This app can be used during training as a training application and the users can enter data in demo mode.

Excel Tricks for Lookup Tables

Below is a list of tips and tricks for managing your Lookup Tables in Excel.

Calculate a Z-Score in a Form