Note: All users assigned to the 'Administration: Account Super User' role can complete the following actions.
Administrators can configure conditional logic between stage fields in issues categories. This allows you to define rules that will automatically hide, show, or require other fields based on the value selected in a primary field.
This feature helps to reduce form complexity by hiding irrelevant fields, improve data quality by enforcing required inputs, and ultimately ensure end-users only see and fill out the necessary information based on their selections.
Where You Can Configure Conditional Logic
Conditional visibility and requirement logic can be configured in:
Stage Custom Fields (inside a specific stage)
Account Custom Fields added to a stage in Issues or Change Controls
To begin, open a category’s configuration page and, within a stage, select add a field to this stage. This can be either a stage or account custom field. Then, open the field editor for any custom field in that stage. Once you select a field type, the add dependent fields toggle becomes available.
Note: Text, Date, and Role/User Select fields do not support dependency configuration.
Enabling Conditional Logic
Open the field editor for a custom field.
Select the field type.
Enable the add dependent fields toggle.
A configuration area will expand, containing:
Condition section
Dependency Rules section
Click save after finishing your configuration.
Configuring a Condition
The condition defines when the dependent fields should appear or become required.
1. Choose the Operator
Operators available depend on the field type:
2. Choose the Value
The input adapts to the field type. For example:
Yes/No → dropdown with 'Yes' / 'No'
Single/Multi Select → dropdown with predefined options
Note: A condition cannot be duplicated with the exact same operator and value.
Example: If “Equals = A” is already used, it cannot be selected again in another condition using “Equals”.
Adding Dependency Rules
After defining the condition, you can specify which fields should be:
Is Visible → hidden until the condition is met
Is Required → always visible, but become mandatory when the condition is met
Important Rules
A custom field can only be added once as a dependent.
Required fields at custom-field configuration level can only be controlled with visibility, not as “is required” on dependency rule level.
You can add multiple dependency rules using Add Another Rule.
Each rule can be removed using the trash icon.
Conflict Handling
If a field appears as a dependent in multiple conditions:
“Required” always overrides “Visible”.
Example:
Condition A → Field X is Visible
Condition B → Field X is Required
→ Field X becomes Required if both conditions are triggered.
Icons
Dependent fields display icons to help admins understand their configuration:
Eye icon → Is Visible
Asterisk → Is Required (whether default-required or dependent rule “is required”)
Hovering the icon displays a tooltip: “This field is dependent on <field name>.”
Visibility
Fields marked as Is Visible appear only when the condition is met.
If the condition becomes false, the field is hidden again.
Required
Fields marked as required may be always visible or only displayed when the condition is met
To make a field always visible and required, you must configure the Required setting directly in the dependency rule.
To make a field required only when the condition is met, you must first mark the field as Required in the field editor, and then configure its visibility condition in the dependency rule.
When the condition is true, the field becomes mandatory.
If the condition later becomes false, the field becomes optional again.
Saving Data of Hidden Fields
If a user previously filled a dependent field and it becomes hidden due to a condition change:
The value is preserved.
If the condition becomes true again, the value reappears.
Editing Conditional Logic
You can edit the conditions or dependency rules at any time.
After a custom field is saved, its type cannot be changed.
If you need a new type, delete the field and create a new one.If a field is already a dependent in another rule, you cannot add dependencies to it (toggle disabled).
Examples (TABLE VIEW OPTION)
Example 1: Capturing Change Requests
Controlling Field: The selections in this field, drive whether subsequent fields are visible
The following custom fields would only appear based on the selection made in the type of change field.
If 'Type of Change' is Document Revision
If 'Type of Change' is System Configuration Change
If 'Type of Change' is Product/Process Improvement
If 'Type of Change' is Emergency Change
Example 2: Logging the source of an issue, CAPA, deviation, non-conformance
Controlling Field: The selections in this field, drive whether subsequent fields are required
The following custom fields would be required or optional based on the selection made in the Source of Issue field.
If 'Source of Issue' is Internal, then 'Vendor Name' would be an optional field.
If 'Source of Issue' is External, then 'Vendor Name' would be required.
Example 3: Documenting whether product was impacted during a non-conformance, deviation
Controlling Field: The selections in this field, drive whether subsequent fields are visible
The following fields will only become visible when the user selects 'Yes' for the Product Impacted? field. If 'No' is selected, then these fields remain hidden.
Example 4: Documenting temperature excursion during a deviation
Controlling Field: The selections in this field, drive whether subsequent fields are visible
If 'Issue Type' is Deviation - Temperature Excursion
(OR BULLET POINTS OPTION)
Use Case Examples
Use Case 1 — Showing Additional Details Only When Needed
Scenario:
You want to ask a user for more information only if they select a specific option.
Example:
Parent field: 'Change Reason' (Single Select)
Dependent field: 'Describe the Deviation' (Text)
Condition: If 'Change Reason contains Deviation'
Rule: Dependent field is visible
Outcome:
Users only see 'Describe the Deviation' when they choose 'Deviation' as the reason.
Use Case 2 — Making a Field Required Only Under Certain Conditions
Scenario:
You want a field to become required only when a specific selection is made.
Example:
Parent field: 'Requires Approval?' (Yes/No)
Dependent field: 'Approver Name'
Condition: Equals 'Yes'
Rule: Is Required
Outcome:
Users always see the 'Approver Name' field, but they only need to complete it when 'Yes' is selected.
Use Case 3 — Showing One Field but Requiring Another
Sometimes dependencies affect multiple fields differently.
Example:
Condition: 'mpact Level contains High'
Field A: 'Justification'→ Is Visible
Field B: 'Mitigation Plan' → Is Required
Outcome:
Users see both fields, but only 'Mitigation Plan' becomes mandatory.
Use Case 4 — Multi-Select Conditions
Example:
Parent: 'Affected Areas' (Multi Select)
Values: QA / Manufacturing / Validation
Condition: Contains 'Validation'
Rule: Show 'Validation Summary Report'
Outcome:
The dependent field appears only when “Validation” is one of the selected areas.