Rules

Overview

Rules in AppStudio allow you to apply conditional behaviours and styles to elements within an app based on record data. This enables dynamic, context-aware interfaces. For example, highlighting problematic values, hiding irrelevant information, or locking fields once certain conditions are met.

Rules operate by evaluating a filter condition on a record and, when the condition is satisfied, applying one or more actions to selected target fields.

Use cases include:

1. Hiding fields until a record meets field value criteria which then means they are relevant.

2. Making a field read-only as the record matures through the process.

3. Applying a red bold text style when a numeric value is negative.

Our developers continue to expand the capabilities of the Rules engine, and additional action types will be introduced over time

• How Rules Work

• Adding / Editing a Rule

• Action Use Cases (Hidden/ReadOnly/Style)

How Rules Work

Each rule consists of three core components:

1. Filter – Defines the condition that determines when the rule applies.

2. Target Fields – Specifies the fields affected when the filter evaluates to true.

3. Actions – Determines what happens to the target fields (Hide, Read Only, or Style).

When the filter condition is met for a record, all configured actions are applied to the selected fields.

Adding / Editing a Rule

Rules reside in App Studio and are stored at the App level so are specific to the current application. To access the list of Rules:

1. Log in to App Studio and navigate to the App that needs a Rule
2. Navigate to the Rules folder for the App
3. Click on a pre-existing rule to edit it or click on Add to create a new rule

Description: A meaningful name and explanation of the rule. This helps other app builders understand its purpose and avoid accidental deletion or modification.

Filter: Determines when the rule applies to the Record being viewed. The rule will activate only when the filter condition evaluates to true. This is constructed as an OData filter.

Target Fields: Specifies the fields affected when the rule triggers. 
Note: Grid Field components can be targeted in two ways. If the Rule should apply to an entire Subfield then you can select the Grid Field and then from a secondary property select the Grid Field Subfield. If you would like to target specific cells in a Grid Field then they will appear in the primary Field selection property in the form [FieldID_DataSet_SubField].

Actions: Defines what happens when the filter condition is met. Supported actions include:

• Hidden – The field becomes invisible to the user.

• Read Only – The field becomes non-editable, even if the field itself is normally editable.

• Style – Applies a predefined style configured in the Styles area.

Remember to resync your app after changing Rules in order for them to apply, and remember Styles are only synced after a full log out and log back in

Action Use Cases

Hidden

In a KPI Tracking app, a Reason for Escalation field should only appear when the KPI is escalated.
A rule is created so that when the KPI is not escalated, the Reason field is hidden, keeping the UI clean and focused.

Read Only

In a training module, once answers are submitted, they must be locked.
A rule sets the 1st answer grid sub-fields) to Read Only when a Submitted flag is true.

Style

In a Return on Investment app, negative values should stand out visually.
A rule applies a style (e.g., bold red text) to the numeric field when its value is less than zero.