Have you ever wanted to know how long it takes your respondents to reach a certain point in your survey? Monitor your respondents’ observance of suggested response times for skill assessments? Or maybe even ensure that personally identifiable information (PII) doesn’t get captured in your data analysis?

SurveyCTO calculations can help you do all these things and more. The values in *calculate* field types—which are automatic and hidden—are calculated using expressions and won’t appear in your survey. Continue reading to learn how to get the most out of this simple yet powerful field type. And read our documentation to learn more about all the expressions you can use in your next survey.

### 1. Check whether a response was changed

Have you ever been curious if your respondents fill in answers and then go back and change them? Knowing if they do can reveal important insights about their thought processes or even if later questions prompt them to reconsider earlier ones. To capture both the initial and final responses, create a *calculate_here* field right after the question with the following expression:

once(${fieldname})

Only you will be able to see the hidden field containing the initial response—the respondent’s process of completing the survey will not be altered.

### 2. Create timestamps to determine response duration

For some questions, you might want to determine if respondents completed one or multiple fields in a prescribed amount of time. This can be useful for tests or skills assessments, for example. To capture the total time spent in a form, create a *calculate* field at the beginning of the form and add a *duration()* function. A *calculate* field containing *duration()* is automatically included in SurveyCTO’s form design spreadsheet template, which contains all the definitions or rules of how your form should work. (For more information on form design, watch this introductory video and enroll in our online training course.)

To capture the time that has elapsed from the beginning of the form up until reaching a particular point, create a *calculate_here* field (see below for a description of *calculate_here* fields) at the end point and combine it with* once()* and *duration()*. By using “*once(duration())*” you are able to stamp the desired end time. If you create several pairs of these timestamp *calculate* fields across the form, you can evaluate the length of time respondents take in certain questions or groups by subtracting the start points from the end points. You can also automate this subtraction in another *calculate* field.

### 3. Perform your calculations only once

Would you like to capture the date and time when a specific field is reached? While *calculate* fields update whenever forms load or save and whenever the fields upon which they rely change, *calculate_here* fields only calculate once (the first time the user reaches that point in the form). To find out the exact date and time when a specific point in your form was reached, create a *calculate_here* field with the following expression:

once(format-date-time(now(), '%Y-%b-%e %H:%M:%S'))

You can read more about the difference between *calculate* and *calculate_here* in this documentation topic.

### 4. Easily calculate total hours

There are several situations for which you might want to calculate total hours between two times. Suppose that you are surveying facilities or businesses and ask for open and close times. With SurveyCTO, you can determine the total hours of operation by setting up a calculation that automatically converts the hours into integers and calculates the total amount of hours. Here’s an example of how:

**Closing time – opening time**

int(format-date-time(${closingtime}, '%H')) - int(format-date-time(${openingtime}, '%H'))

This example subtracts opening time values from closing time values, returning an hour value. Depending on your requirements, you may wish to incorporate minute values into the calculation as well. Either way, the above calculation eliminates any manual calculations and reduces the margin for error in determining the total time.

### 5. Create dynamic default values

Do you want one of your questions to have a default value—the date perhaps—that comes from a previous field or from any expression elsewhere in your form? This is particularly helpful if your form has follow-up questions about values that will only be known once earlier fields are completed.

If you would like tomorrow’s date to appear automatically in your date field, for example, insert the following in the *calculation* column:

date(once(today()+1))

With this default value expression in place, your date field will always be dynamically filled with tomorrow’s date by default, rather than today’s date (which is the default behavior).

### 6. Extract information from repeat groups

Calculations make it easy to use previously entered values within repeat groups. If you need any of these values later in your form, this saves you from having to re-enter them and eliminates the risk of entering them incorrectly.

Suppose you are conducting a household survey, for example, and create separate rosters for names, ages, and number of cell phones owned. You can use *calculate* fields to extract the values inside those repeat groups by using the following expressions:

indexed-repeat(repeatedfield, repeatgroup, index)

This will return the value from a specific field within a repeat group so you can use that in follow-up questions and/or subsequent rosters (e.g. the household members names from the first roster).

sum(repeatedfield)

For a field within a repeat group, this will calculate the sum of the values of that field. For example, if you ask each member of a household how many cell phones they own, *sum(${cellphones_owned})* will return how many total cell phones are owned by all the members of the household.

max(repeatedfield)

*or*

min(repeatedfield)

For a field within a repeat group, this will return the maximum or minimum value from all the instances of that repeated field. For example, you can use this to calculate the oldest and youngest member of a household.

These are just a few of the expressions you can use. To explore more, read the documentation.

### 7. Using relevance with calculate fields

Suppose you want to use personally identifiable information (PII) in your form but not present it in your form datasets. To do so, relevance expressions can be applied to *calculate* fields. Since relevance expressions control whether or not a field or group (including hidden fields) is included in the finalized version of the form, you can use them to clear the value of a *calculate* field before the form is finalized. For example, if you are using a *calculate* field to pull in PII from another source for the purpose of verifying the identity of a respondent, simply apply a relevance condition to that *calculate* field that will make that field irrelevant by the time the form is finalized. When the form is finalized, all the expressions in your form (including relevance and calculations) will be updated, and the PII stored in that *calculate* field will be cleared if it is no longer relevant.

Another use case is if you need to ask many separate questions during the survey, but only want to include one calculated result in your data. You can create a *calculate* field and use the *once()* function to make sure it only calculates once, then make all the individual question fields irrelevant after you’ve performed your calculation. For example, you could create a group of questions asking about the number of each type of room in a household (e.g., bedrooms, bathrooms). If you apply a relevance condition to this group, it’ll make the questions relevant while the form is being filled out, but then make them irrelevant by the time the form is finalized. Then create a *calculate* field with the following expression:

once(${n_bedrooms} + ${n_bathrooms} + ${n_other-rooms})

This *calculate* field will run once, add up the total number of rooms, then store the result in that *calculate* field. Since you used the *once()* function, the total number of rooms will remain stored in that field, even after the question fields themselves have become irrelevant. The submitted data will contain the total number of rooms (stored in the *calculate* field), but not any of the questions asking about specific room types.

### 8. Divide long and complex logic across multiple calculate fields

If you have a lot of considerations to incorporate into the logic of an expression, you can end up with a long and complex expression. For example, perhaps you need the total list of nutritional values for every food item consumed by a household member during a period of time, and the list is lengthy, totaling over 40 items. Instead of adding these values in a single *calculate* field, split them across multiple *calculate* fields, and add another *calculate* field to sum their values.

This will make it much easier to manage and troubleshoot your calculations while designing the form, and will give you the option of seeing intermediate steps in the calculations in the final data.

If the devices you will be using to fill out your form have low memory capacity, lengthy expressions might affect the performance of the SurveyCTO Collect mobile app. Splitting them up into shorter expressions helps to ensure that your form is optimized for the hardware you have! Splitting them also provides more insight into the logic of your form, making any errors easier to fix.

### 9. Don’t fret about order

All logic, including expressions in *calculate* fields, evaluates at specific points:

- When the form is launched.
- When values being called in from other fields within a form are changed.
- When you save the form.
- When you finalize the form.

Since calculation expressions re-evaluate throughout the completion of a form, it doesn’t matter where you put them within a form. There are two exceptions to this: *calculate_here* fields and *calculate* fields placed inside repeat groups. As explained in this post, *calculate_here* only applies to specific fields. And the most common reason to put a *calculate* field inside a repeat group is because there’s something to calculate relative to the position number of the repeat group.

Instead of worrying about the exact order of your calculation expressions, you can use the time you’ve saved to focus on other parts of your data collection project.