Custom Fields

Custom fields are the building blocks of incident templates. They define what data is collected for each type of incident. This page provides a complete reference of all supported field types, their behaviour, and how to use conditional visibility to create dynamic forms.

Field types

Type	Input	Use case
Text	Single-line text input	Short answers: names, codes, descriptions.
Number	Numeric input (supports decimals)	Measurements: pressure, diameter, distance, cost estimates.
Select	Dropdown menu with predefined options	Categories: priority levels, leak types, damage severity.
Textarea	Multi-line text input	Longer descriptions, detailed observations, repair notes.
Date	Date picker	Scheduled dates, inspection dates, follow-up deadlines.
Checkbox	Boolean toggle (checked/unchecked)	Yes/no questions: “Requires excavation?”, “Public safety risk?”.

Field properties

Every field, regardless of type, has the following properties:

Property	Required	Description
Label	Yes	The field name shown to users. Supports multiple languages (English, Spanish, Portuguese).
Name	Yes	Internal identifier used for data storage. Set automatically from the label and cannot be changed after creation.
Type	Yes	One of the types listed above. Cannot be changed after creation.
Required	No	If enabled, the user must fill in this field before saving the incident. Default: not required.
Options	Select only	The list of values available in the dropdown. Each option is a text string.
Conditional visibility	No	Rules that determine when the field is shown or hidden. See below.

Configuring select field options

For select (dropdown) fields, you define the list of options that users can choose from:

1. Open the template in the template builder.
2. Click on the select field you want to configure.
3. Add each option as a separate entry.
4. Reorder options by dragging them into the desired position.
5. Save the template.

Users will see these options in a dropdown when creating or editing an incident. The first option is not pre-selected — the user must actively choose a value.

Conditional visibility

Conditional visibility allows you to show or hide fields based on the value of another field. This is useful for creating dynamic forms that adapt to the user’s input without requiring multiple templates.

Note

Only select and checkbox fields can be used as a parent (trigger) for conditional visibility rules. Text, number, textarea, and date fields cannot trigger visibility conditions.

Setting up a condition

1. Open the template in the template builder.
2. Click on the field you want to make conditional.
3. In the Visible when section, configure:
   • Parent field — The select or checkbox field whose value determines visibility. The parent must appear earlier in the field list than the dependent field.
   • Operator — The comparison to apply. The available operators depend on the parent field type (see below).
   • Value(s) — For select-based operators, choose one or more of the parent field’s options.
4. Save the template.

Operators for select fields

When the parent is a select (dropdown) field, the following operators are available:

Operator	Behaviour	Example
equals	Field is shown when the parent’s value matches exactly one value.	Show “Pipe Material” when “Category” equals “Water Leak”.
not equals	Field is shown when the parent’s value does not match the specified value.	Show “General Notes” when “Category” does not equal “Other”.
in	Field is shown when the parent’s value is one of several selected values.	Show “Severity Detail” when “Priority” is “High” or “Critical”.
not in	Field is shown when the parent’s value is not in the selected list.	Show “Low Priority Note” when “Priority” is not “High” or “Critical”.

All four operators require you to select one or more values from the parent field’s options.

Operators for checkbox fields

When the parent is a checkbox field, the following operators are available:

Operator	Behaviour	Example
truthy	Field is shown when the checkbox is checked.	Show “Follow-up Date” when “Requires Follow-up” is checked.
falsy	Field is shown when the checkbox is unchecked.	Show “Reason Not Assigned” when “Assigned” is unchecked.

These operators do not require any value selection — they respond solely to whether the checkbox is checked or not.

Chained conditions

Conditions can be chained across multiple levels. If field B depends on field A, and field C depends on field B, then field C will only appear when both conditions are met. Nexalix evaluates the full chain automatically.

When a parent field’s value changes and causes a dependent field to become hidden, the hidden field’s value is automatically cleared to prevent stale data from being saved.

Ordering rules

• A parent field must appear before its dependent field in the field list.
• If you reorder a field so that it appears after a field that depends on it, the condition is automatically removed.
• If a parent field is deleted, all dependent fields lose their visibility condition.
• If a parent field’s type is changed from select or checkbox to another type, all conditions referencing it are cleared.

Best practices

• Use select fields for structured data. When users need to choose from a known set of values, a select field is always preferable to a text field — it ensures consistency and enables meaningful statistics.
• Keep option lists manageable. Dropdown menus with more than 15-20 options become difficult to use in the field. Consider splitting into two fields (e.g., “Category” then “Sub-category” with conditional visibility).
• Mark fields as required only when necessary. Field teams working in adverse conditions need to submit reports quickly. Every required field adds friction.
• Test conditional visibility before deploying. Create a test incident to verify that fields appear and disappear correctly as you change parent field values.