Conditional Logic in Forms

Conditional logic allows you to dynamically control how fields and sections behave in Flex form DataParts based on values entered by app users. Conditional logic rules allow your forms to automatically show, hide, enable, disable, or require form elements depending on specific conditions.

For example, a form can display additional fields only when an app user selects a particular option. A form can require extra information for certain responses or disable fields that are not relevant in a given situation. Conditional logic helps keep forms shorter and easier to complete by displaying only the information that is relevant at each step.

A typical rule consists of one or more conditions and one or more actions. Conditional logic rules automatically evaluate field values within the current DataPart when the form loads and when any value changes. Conditions compare field values using operators appropriate for a given field data type, and they can compare a runtime field with another field or with a static value. Conditions can also be grouped using AND and OR logic, allowing you to build more complex nested condition groups of up to six levels. When a rule’s conditions are met, its action is applied.

Conditional logic supports the following data types in rule criteria: Text (255), Text (64000), Number, Integer, Currency, Date/Time, Yes/No, Random ID, Autonumber, Prefixed Autonumber, and GUID. Formula fields are evaluated according to the data type returned by the formula. If the resulting type cannot be determined, the value is treated as text.

Conditional logic is supported in Submission, Details/Update, and Search Forms.

Rules operate only within the current DataPart and cannot reference fields from other DataParts.

Examples:

• In a registration form, you can configure a rule that shows the Company Name field and makes it required when the app user selects Business in the Account Type field. This ensures that company information is collected only when the app user is registering as a business.
• In a service request form, you can configure a rule that displays a Manager Approval field when the Estimated Cost entered by the user exceeds a defined threshold such as 5000. This allows approval fields to appear only when additional authorization is required.
• In a job application form, you can configure a rule that displays a Previous Employer section when the applicant selects any work experience option other than None. This keeps the form shorter for applicants without prior experience while allowing additional information to be collected when needed.

Creating rules

1. In a Form DataPart configuration right panel, under Conditional logic, click Add.
2. In the panel that opens, enter a name for your rule.
3. In the Under the following conditions section, create a condition based on which this rule will execute:
   
   1. Click Add condition.
   2. Select a form field whose value will be compared.
   3. Select the comparison type.
   4. Select the value for comparison:
      
      • If you want to enter the value, select Static value and enter the value.
      • If you want to dynamically compare with another field value, select Runtime field.
   5. Optional: If needed, add multiple conditions. If you do, select whether all conditions should be met (AND) or only one condition can activate the rule (OR).
      
   6. Optional: To build more complex conditional logic, click Add group to create nested levels of criteria. Use AND and OR as required.
4. In the Run this action section, configure what happens once this rule’s condition logic is fulfilled:
   
   1. Click Add action.
   2. Select the action type:
      • Show – Displays the targeted field or section when the rule conditions are met.
      • Hide – Conceals the targeted field or section so it is not visible to the app user.
      • Enable – Allows app users to interact with the targeted field or section and enter or modify values.
      • Disable – Prevents app users from interacting with the targeted field or section.
      • Make required – Requires app users to provide a value in the targeted field before the form can be submitted. Available for fields only.
      • Make not required – Removes the requirement to enter a value in the targeted field. Available for fields only.
   3. Optional: If your rule hides or disables a field or section, and you want the form to save the value of the hidden or disabled fields, select the Save hidden/disabled field values on form submission checkbox.

   Note: Fields hidden or disabled by conditional logic remain available to Calculated Values regardless of whether this option is used. Calculated values always evaluate using the current field values stored in the form model.

   4. Select whether the action should apply to a field or a form section.
   5. Select the specific field or form section to be affected by this rule.
   6. Optional: If needed, add multiple actions to run based on this rule’s condition logic.
5. Save the rule by clicking Save.

In the Conditional logic section, you can edit your existing rules, as well as disable and enable them as required.

How field values are evaluated

Conditional logic dynamically evaluates actual values in the form fields.

A condition is met explicitly when its specific criteria are satisfied (for example, a rule shows the Company Name field when Account Type = Business, and the user selects Business). An implicit behavior occurs when the system derives a field state indirectly from other rules whose conditions are not met. For example, the same field remains hidden when Account Type is not Business because the “show” action condition is not satisfied.

When multiple rules apply conflicting actions, the final state is determined using predefined precedence logic. Rules whose conditions are explicitly met take precedence over behavior that would otherwise occur implicitly.

Example: In a registration form, Rule 1 is: when the Account Type is set to Business, show a Company Details section:

Without any other rules, the section would implicitly remain hidden for all account types other than Business because the show condition is not met. However, Rule 2 explicitly specifies that the Company Details section should also be shown when Account Type is Partner:

When the condition of Rule 2 is explicitly met for a Partner account type, Rule 2 overrides the implicit behavior of Rule 1 (to hide the section for all account types other than Business). As a result, the section appears for both Business and Partner selections.

When there are conflicting explicit rules, the following precedence applies:

• Hide overrides Show.
• Disable overrides Enable.
• Make not required overrides Make required.

If multiple rules hide or disable a field with different save configurations, the rule that preserves the value takes precedence. This ensures that if any rule explicitly specifies that a value should be retained, the value will be saved.

Use rules that apply both Hide and Make required to the same field with caution, because the form cannot be submitted if a required field is hidden and does not contain a value.

Here is how field values are evaluated for various form elements:

• Checkbox fields – The rule engine evaluates the value defined for the checked state. An unchecked checkbox is treated as a null value.
• Dropdown, radio buttons, listbox, and AutoComplete (Force selection enabled) – Comparisons use the stored value defined in the lookup configuration or custom values.
• AutoComplete (Force selection disabled) – The rule evaluates the value typed directly by the user.
• Yes/No fields – Values are evaluated as Yes or No.
• Calculated fields – The rule evaluates the value returned by the calculation formula.
• Hidden elements and default values – Hidden form elements can still be used in rule conditions, but not in actions. Default field values are evaluated when the form loads.

If a numeric field is empty during comparison, it is treated as 0.

Using conditional logic in Search Forms

Search Forms do not store data in the database but can preserve values within the user session.

If the option to save hidden or disabled values is enabled, values from those fields remain available as DataPart field parameters. If the option is disabled, blank values are sent instead. This allows Search Forms to act as a parameter collection step before redirecting users to another AppPage where DataParts use those parameters to filter results.

For example, a Search Form can collect filtering criteria and redirect users to a results page while preserving parameter values even if some filter fields were hidden based on earlier selections.

Limits and restrictions

Each DataPart can contain up to 50 conditional logic rules. Within a single rule, you can define up to 50 conditions and 200 actions.

Conditional logic rules operate only within the current DataPart. Criteria cannot reference fields from other DataParts, and hidden form elements cannot be used as targets for rule actions.