# Calculated variables

Create derived variables by writing functions optionally using other variables

**Calculated variables** allow you to define and calculate new answers based on other answers present within the flow, by writing simple functions that are evaluated within Formsort.

Common uses of calculated variables include:

Formatting answers

Capturing conditional logic that cannot be easily expressed

Performing math on numbers or dates

Calculated variables behave just like any other answer: they can be used for conditions, templated into most text, and are sent to your analytics and integrations.

## Adding a calculated answer

From the **Variable **tab, select **Calculated variables**, and click **Add calculated variable...**

### Variable type

Sets the expected data type that we are expecting the calculation to return: `string`

, `number`

, or `boolean`

### Is array?

If **Is array? **is enabled, then we will expect the response to contain multiple answers.

### Getter function body

The **Getter function body **contains the Typescript code function body for the calculated answer.

For example, the following getter function body will result in the date 6 months from the current date:

To use existing answers within a getter function body, add the answers as variables. The following calculated variable will calculate the length of the answer variable labelled `first_name`

The `myFunction() { ... }`

part of the getter function body is auto-generated and cannot be modified.

For more examples on creating calculating variables, see Useful calculated functions at the bottom of this page.

### Optional Variables

If any of the parameters to `myFunction`

are optional, such as in the case of API variables that may or may not be passed in, make sure to check the **Optional** field next to the variable.

If a variable that is *not* optional is *not* passed to the function, the Getter function will not execute correctly!

## When are calculated variables evaluated?

If a calculated variable has no answer dependencies, it is evaluated at the time that the flow loads.

For calculated variables with dependencies, by default, calculated variables are only evaluated once all of their required (non-*optional*) input variables are defined. If any of the required input variables become undefined, the calculated variable is cleared.

Imagine the following calculated answer, which uses the javascript Math.max function to find the larger of two numbers, and we'll call `largest_number`

:

If only one or none of the input answers are defined, `largest_number`

will remain undefined.

Only when all of the input answers are defined will the calculation occur.

For calculated variables with optional dependencies, the calculated variables will be evaluated before the optional dependencies have a value, and will then be re-evaluated whenever an optional dependency receives a value, such as in the case of a responder providing a value for an answer variable.

#### Blocks advancing from current step?

Calculated variables are handled asynchronously, and the default calculated variable configuration does not guarantee that the variable will be available by the time answer payloads are submitted. For instance, if a calculated variable finally receives the dependencies it needs on a step that will also send a payload (see submission frequency), the user might advance past the step before the calculated variable has time to finish it's calculations and attach the result to the payload, resulting in a seemingly missing calculated variable.

Enabling **Blocks advancing from current step?** in the configuration menu of your calculated variable will prevent the user from advancing past a step until calculations are finished processing. If no calculations have started yet (i.e. not all the dependencies are in), the step will not wait for the variable and the user will proceed. This ensures that calculated variables are present as the user proceeds through the flow, which helps to prevent logic errors down the line, and maintains data fidelity in the answers sent to your endpoint.

### Conditional evaluation

For more control over when the calculated variable is evaluated, you can set a condition using **Is conditional?**

When using conditional evaluation, you must take care to handle `undefined`

answers within the getter function body.

Using the above example of `largest_number`

, we could add a condition using Advanced logic to run the calculation whenever either number is defined.

Now that we're evaluating the calculation even when the inputs are undefined, we need to change the getter function body to handle this case.

### Re-calculate on load

If a calculated variable was calculated in a previous session, and the responder returns to the flow, the default behavior is *not *to re-calculate the answer.

To always recalculate the answer on load, enable **Re-calculate on load**. This is useful for situations when calculated variables are not idempotent, meaning that repeated invocations do not result in the same result, such as answers depending on the current date or time.

Unless you need the variables in the answer's payload, avoid using this option as it has performance implications. Step conditional logic waits for calculated variables by default. Donโt use this option to ensure the conditional logic within the form is applied correctly.

## Useful calculated variable function examples

#### Get age from DOB

We can calculate a responder's age based on the date they enter for answer variable `patient_dob`

in this example.

#### Calculate amount of days from today

Using this function, we can calculate the amount of days that have (or will) elapse from a date before or after today.

#### Check responder answer against a list

This function will return a boolean true/false value, based on whether or not the responder's answer to `State`

is included in a list.

#### Calculate BMI

This function requires a `height`

and `weight`

input, and will return a calculation of the users Body Mass Index.

Last updated