Conditional Fields¶
This feature is about the ability to use conditions to create a more dynamic client configuration. Some client metadata attributes can be enabled and disabled conditionally, while for some attributes the actual value can be conditionally assigned.
By taking advantage of these capabilities, it is possible to simplify the UI so that the system is guiding the user through the business process. It also enforces data integrity too by reducing the number of possible mistakes from the user. This is done by conditionally reducing selections available within a drop down based on other fields, enforcing mandatory fields based on a selection on another field etc.
Conditional Attribute¶
Conditional attributes are the attributes in the client metadata that can be either Boolean true / false or a condition. E.g., visible, editable, required. In the image below the "editable" attribute is defined as a condition only allowing the Context field to be editable during insert, before the the record gets its "etag" set; while attribute "required" is statically set to true.
Conditional value¶
Conditional values are attributes where the value is selected by evaluating a hierarchy of conditions. Each condition is evaluated until a positive result is found and the specified value for this case is selected. E.g., LOV filter, Enumeration filter.
In this image a filter is applied in a conditional value construct. If the record attribute "Context" is set the filter value that is using the "Context" value is to be used. If not, use the second filter value.
Not all values in the client metadata can be conditionally set, only a small set of values that are designed to be so, support this conditional construct.
Switch input type¶
It is possible to switch between input types. For an attribute that supports conditions but currently holds a Boolean value and displays a checkbox, press the switch to condition command to change input to an input field. Same command button is used to switch from an input field to a checkbox.
Scenarios¶
Filter Enumeration Values Conditionally¶
To be able to guide the user to correct data input for the business process it may be practical to limit the value list for enumerations. For enumerations it is possible to specify a condition hierarchy that provides the set of values that should be available for a specific situation. Please refer Filter Enumeration Values.
Filter LOV’s Conditionally¶
End users want to avoid having long drop-down lists where possible and reduce the possible selections available to make their decisions on what value to select easier. For LOV’s it is possible to specify a condition hierarchy that filters the returned list for a specific situation. Please refer Filter List of Values.
Conditional Mandatory Fields¶
Your business process may mandate other fields to be mandatory than what the standard application does.
A field can be set to be required based on a condition, this allows you to increase data integrity and removes the need for an end user remembering to enter or select something in a field.
Conditional Read Only Fields¶
You might want to be able to control what fields can be edited within your business processes. This can be controlled by setting a field to be editable based on a condition. This increases data integrity and removes the need for an end user remembering process rules.
Show/Hide Fields Conditionally¶
You might want to be able to control what fields should be visible or not within a business process. A field can be set to be visible or not based on a condition. This provides a more dynamic behavior in the user experience. Being able to show or hide fields that are needed for a particular process allows for a more intuitive user experience where the system guides the user to follow the correct business process.