Introduction
There are various ways in which fields can be populated but some have precedence over others. This means that some types of values overwrite others. There is an order in which Forms evaluates the value of a field.
Order of Field Evaluation
1. User Input: the value entered by the user filling the form will overwrite any other value, whether this be the default value of that field or previous stage data.
2. Previous Stage Data: if there are two instances of a field with the same data name in two different stages, the value will be carried across from the first stage into the second stage. This is known as token population and can be turned off for individual fields in a stage. This value is only overwritten by user input.
3. Reserved Datanames: there are certain datanames that can be used any time within the platform that will always pull through certain type of data. An example is 'First_Name' which will always bring in the first name of the user from their Self account. A field populated by a reserved dataname will be overwritten by previous stage data and user input. Reserved datanames should therefore not be used as an input field unless you are intending to use the token itself. Using reserved tokens will mean default values may be imported from the token.
4. Default Value: a field can also be populated by a default value such as a calculation or an environment token. Environment tokens are custom tokens that you can set to always have the same value, an example of a common use for these being API keys. Default values, however, are overwritten by reserved data names, previous stage data, and user input.
The above, however, is not the case for read-only fields; the order of field evaluation changes. In a read-only field, the default value takes precedence over all other types of value.
Note: In Service, if you have a field which has a reserved data name in the first stage, but the field remains blank, when pulling this data into a second stage, it may be populated by the CSA's details. In the second stage, as there is a field with a reserved data name which is blank, the form still tries to populate the field with data.
A common example of this issue is with the 'Email_Address' reserved data name. In Service, if the citizen does not have an email address, then this will remain blank in the first stage. When pulled through to the second stage, however, this field will be populated by the CSA's email address.
A solution to this issue is to hide the 'Email_Address' field and have it populate a second email address field which has a different data name. The second email address field will have its default value set to {Email_Address}. The token of the second email address field can then be used in other stages and it will not be populated by the CSA's email address if left blank.
Autolookup evaluation
Fields evaluation of the form is triggered every time a change occurs, and if fields rely on one another, this can trigger a chain of evaluation passes. For example, if there are conditions that will populate a field according to one that comes later.
So depending on form design, it is possible for an autolookup lower down on the form to be triggered first (in the first evaluation pass of a chain) followed by an autolookup higher up the form to trigger second (during a later evaluation pass in the chain).
Examples and Common Mistakes
-
If you use the 'Copy Fields' functionality to copy fields from an earlier stage to later stages and to make them read-only, be careful of leaving the original default values in the fields. If you copy fields across with their default values (eg. a calculation) and make them read-only, the default value will take precedence and erase the data from the earlier stage. In the case of a calculation, it is likely that the calculation will not be able to work because the other fields it uses to calculate the value don't exist in the next stages, so it evaluates to a blank field.
Common Solutions
- Default values will not override a reserved dataname but you can use a database lookup to achieve the same outcome. This can be used to select Field A as Field B.
- Some datanames cause unexpected issues and act as if they were reserved data names at times. For example, a field should never have the dataname 'email'.
