Business Rule

---

Business rules provide an automated configuration mechanism for worksheets. They allow you to dynamically adjust field states (show, hide, read-only, editable, required), modify field values, lock records, or validate user actions based on conditions when records are created, edited, or viewed.

Common use cases include:

• Dynamically show or hide fields based on business logic
• Set fields as read-only, editable, or required based on conditions
• Validate data and provide instant feedback or block saving
• Automatically lock records when conditions are met to prevent further changes

Examples

Below are some typical use cases of business rules:

• Example 1: Conditional display and hiding

  When scheduling an interview, selecting “Video Interview” displays the “Meeting Link” field; selecting “On-site Interview” displays the “Meeting Room” field and clears the meeting link automatically.

  

• Example 2: Dynamic data validation

  If the “Outbound Quantity” exceeds the dynamic “Current Inventory,” saving is blocked and an error message is displayed.

  

• Example 3: Lock records based on status

  When a task is marked as “Finished”, all fields in the record become read-only and cannot be edited.

  

Configure Business Rules

Application administrators can select the target worksheet and navigate to:
[Edit Form] > [Form Settings] > [Business Rule]

Tip: A maximum of 100 business rules can be enabled at the same time.

Rule Structure: Conditions and Actions

A business rule consists of conditions and actions. When the defined conditions are met, the system executes the corresponding actions.

Conditions

You can define a single condition or multiple combined conditions. Each condition consists of field + operator + value.

• Fixed value:
  Compare with a static option or value (e.g., “Interview Type” equals “Video Interview”)

• Field value:
  Compare values between two fields dynamically (e.g., “Outbound Quantity” is greater than “Inventory”)

Actions

Actions are grouped into four categories: field interaction, field styling, field validation, and record locking.

Field Interaction

Supports the following actions:

• Show / Hide
• Read-only / Editable
• Required
• Set field value
• Set all fields to read-only

Note:
“Set all fields to read-only” takes effect after the record is saved. Once applied, users cannot edit fields directly, but fields can still be updated via custom actions and workflow.

Field Styling

Field styling allows you to dynamically adjust the visual appearance of fields based on predefined conditions. This data-driven approach helps users quickly identify critical information such as low inventory, high-risk orders, or to-do items.

Supported styling options:

• Field title:
  Modify color, font style (bold / italic / underline / strikethrough), and font size

• Field value:
  Modify color, text style, and font size

Configuration methods:

1. Configure in business rules
   Suitable for complex scenarios involving multiple fields. Define styles at the worksheet level.

2. Configure in field properties
   Suitable for quick styling of individual fields. Add rules directly in the “Style” panel on the right side of the field.

Example:
When the outbound quantity exceeds the inventory, the “Outbound Quantity” field is displayed in larger red text.

Display result:

Field Validation

Compare field values and prevent record saving when validation conditions are met, with prompts displayed to the operator.

Supports configuration of:

Alert messages

When to display alerts

When to perform data validation

Validation Timing

• If "Real-time prompts when entering fields" is checked, validation occurs when condition fields are being input or lose focus.

• If "Re-validate when saving data to server" is checked, the system performs additional validation against database values when saving records, preventing errors caused by background data changes during editing.

  Example: During product shipping, the system reads current inventory levels. The page's inventory quantity won't automatically update if other users modify actual inventory. Thus, revalidating against server data upon saving ensures accuracy.

Field-Specific Prompt

Supports displaying prompts on specified fields.

Choose whether to block submission or allow submission with warnings

• Block Submission

  If the error message appears in red, the system will block the submission when you try to save the record.

  

• Allow Submission with Warnings

  If the error message appears in yellow, the system will prompt the warning again when saving, but allows the record to be saved by ignoring the warning.

  

Lock Record

You can configure a business rule that automatically locks a record after it is saved (either on create or edit), if it meets the conditions defined in the rule.

The lock description will be shown on the record when it is locked by business rules, and also when a record is manually locked by the app admin.

• The filter conditions only support single-select, multi-select, and check items fields.

• Modifying the conditions of a business rule will not retroactively change the locked status of existing records. The rule will only apply the next time a record is saved and evaluated.

Example Demonstration

Show or hide fields when conditions are met

Example: When scheduling interviews, there are two types: on-site interviews and video interviews.

• For on-site interviews, show the Meeting Room field and hide the Meeting Link field.

• For video interviews, show the Meeting Link field and hide the Meeting Room field.

Worksheet Fields

The worksheet contains three fields:

• Interview Type (dropdown: "Video" or "On-site")

• Meeting Room

• Meeting Link

Objective:

• If "Video" is selected in Interview Type, hide Meeting Room and show Meeting Link.

• If "On-site" is selected, hide Meeting Link and show Meeting Room.

Configuring Business Rules

Condition: When "Interview Type" equals "Video interview"

Actions: Show Meeting Link, Hide Meeting Room

Effect

Beginners might add another rule for "On-site", but it’s actually optional.

Reason: In business rules, if you configure an action (e.g., hide/show) for a condition, the opposite action automatically applies when the condition is not met.

In this example:

• If "Interview Type" is not "Video" (i.e., "On-site"), the system will:

  • Hide Meeting Link

  • Show Meeting Room

This happens because "Hide" and "Show" are complementary actions. View Details

Prompt operator after comparing field values

Example: When processing product outbound shipments, if the outbound quantity exceeds current inventory levels, prevent record saving and notify the user.

Configuring Business Rule

Create the business rule under the "Validation" tab with these settings:

• Condition: When Outbound Quantity > Inventory

  Since inventory levels change dynamically, compare against the real-time Inventory field value.

• Prompt Message:

  Customize the prompt message as needed (e.g., "Insufficient inventory").

  The prompt can be displayed directly on specified fields—in this example, it will appear on both the Inventory and Outbound fields.

• Validation Options:

  [Real-time prompts when entering fields]:

  • If enabled, prompts will appear immediately when entering values.

  • If disabled, prompts will only appear upon submission or saving.

  [Re-validate when saving to server]:

  During record editing, the retrieved inventory quantity may have been modified by other users. To ensure inventory accuracy, enable this option, which performs dual validation to guarantee data consistency.

Effect

When editing fields involved in the condition, error prompts will appear directly on the affected fields.

Basic Operations for Business Rules

• View/Edit rules
• Delete/Copy rules
• Sort rules
• Enable/Disable rules

Execution Logic of Business Rules

The interaction actions in business rules follow a mechanism of “override + fallback + merge” applied to field properties.

0. Field "Original Properties"

Each field has its own default properties configured in advance:

• Hide / Show
• Read-only / Editable
• Required

When business rules are not applied, fields revert to these original property states. The term “fallback” refers to returning to this state.

1. Execution Logic Based on Rule Conditions

Business rules follow an opposing execution logic. When a rule is triggered, its actions will override the field’s original properties. When the condition is not met, the system either performs a reverse action or falls back to the original properties, depending on the action type.

Field Visibility: Strictly Opposing

Show and Hide are strictly mutually exclusive. Once a business rule is applied, it fully controls the field’s visibility and forcibly overrides its display setting.

Rule Action	When Condition Is Met	When Condition Is Not Met
Show	Show	Hidden (forced)
Hide	Hidden	Show (forced)

💡 Tip: You do not need to create reverse rules. The system automatically handles the state when conditions are not met.

Example:

A business rule is configured as: “When Interview Type is ‘Video’, show the ‘Meeting Link’ field.”

When the user switches to “On-site Interview” (condition not met), the “Meeting Link” field will be automatically hidden. No additional rule is required.

Editable and Required: Property Fallback

Actions such as Edit, Required, and Read-only take effect only when the condition is met and the field is visible. When the condition is not met, the action is removed, and the field falls back to its original configuration.

Action	When Condition Is Met	When Condition Is Not Met
Editable	Editable	Falls back to original property
Required	Required	Falls back to original property
Read-only	Read-only	Falls back to original property
Read-only all fields	Entire record is read-only	No change (no action applied)

⚠️ Note: These actions do not force hidden fields to become visible.

Example:
If Field A is originally set to Read-only, and a business rule states: “When Amount > 100, Field A becomes Editable”.

• When Amount ≤ 100 (condition not met), Field A will revert to Read-only.

  Note: It becomes read-only because of its original property—not because the opposite of “Editable” is “Read-only”.

2. Priority Among Multiple Business Rules

When multiple business rules control the same field simultaneously, the system aggregates all rule actions and applies them based on the following priority order:

Hide > Show > Read-only > Required > Editable

Logic Explanation:

• Hide (Highest Priority):
  Once a field is hidden, all interactions and validations are blocked.

• Read-only vs Editable:
  Read-only has higher priority than editable. In case of conflict, read-only takes precedence.

• Required Validation:
  The required rule only applies when the field is in an editable state.

Rule Combination Examples:

• Visibility Conflict:
  Rule A sets Hide, while Rule B sets Show.
  After aggregation, since Hide has higher priority, the final result is: Hidden.

• Dimension Combination:
  Rule A sets Show, and Rule B sets Editable.
  After aggregation, the final result is: Visible + Editable.

• Permission Conflict:
  Rule A sets Show, Rule B sets Editable, and Rule C sets Read-only.
  After aggregation, the final result is: Visible + Read-only (read-only overrides editable).

📌 Note:
The above results only reflect how multiple business rules are resolved internally. The final field state is determined after merging this result with the field’s original properties and external configurations (such as role permissions or workflow).

Common Misconfiguration: Why Is the Field Always Hidden?

When multiple rules control the same field, the following conflict is common:

Incorrect Example:

As shown below, two separate rules are configured to show the Promotion Activity field:

• Rule 1: Show the field when Lead Source = “Ad Campaign”
• Rule 2: Show the field when Lead Source = “Email Campaign”

• Root Cause Analysis:

  Since Lead Source is a single select field, only one value can be selected.
  When the value is “Ad Campaign”, Rule 1 is satisfied, but Rule 2 is not satisfied.

  According to the visibility opposition principle, Rule 2 will trigger a forced Hide action when its condition is not met.

  As a result, the two rules conflict, and the system applies the highest-priority action (Hide > Show), causing the field to remain hidden

Correct Configuration:

For the same field, it is recommended to consolidate conditions into a single rule using OR logic.

3. Priority Between Business Rules, Views, Role Permissions, and Workflow

Field properties may be affected by multiple sources simultaneously:

• Field original configuration
• Business rules
• Views
• Role permissions
• Workflow / Custom Buttons

The system aggregates all sources and applies them based on the following priority:

Hide > Show > Read-only > Required > Editable

4. Special Rules and Scenario Limitations

"Hide when Create" Always Takes Effect

If a field is configured as Hide when Create, it will be always hidden when creating a new record.
Any Show action from business rules will not take effect at this stage.

Scope of "Read-only All Fields"

The Read-only All Fields action in business rules only applies when operating directly within the worksheet. When opening a record from the worksheet, all fields become non-editable.

However, data can still be modified through the following methods:

• Editing fields via Custom Buttons
• Editing records opened through workflow nodes such as Fill-in Node, Approval Node, or Send Internal Notification Node

👉 To fully lock a record, use Edit Lock.

Action Downgrade in Table View

In table view (with business rules enabled), some actions are downgraded due to interaction limitations at the cell level:

Action	Actual Effect
Hide	Read-only
Required	Editable (not enforced)

Rule Effectiveness When Fields Are Hidden

When fields involved in business rules are not visible, rule execution may be affected. Different action types follow different logic.

Business rule actions can be divided into two categories:

• Error Prompt
• Non-error Actions
  • Show, Read-only, Hide, Required, Editable, Lock

1. Logic for Non-error Actions

• When viewing records in the detail page, as long as the condition fields exist and are not deleted, the business rule will execute.

• In table view and org view (tree table):

  • As long as condition fields exist and are not deleted, Read-only and Editable actions take effect
  • Other actions do not take effect

• In other views, business rules do not take effect.

2. Logic for Error Prompts

• Case 1: A > 0 → Show error: xxx

  Example: If outbound quantity < 10 → Show error: “Each outbound quantity must be greater than 10.”
  If the outbound quantity field is hidden, no error will be triggered.

• Case 2: A > B → Show error: xxx

  • If only one of A or B is hidden → Rule executes normally
  • If both A and B are hidden → Rule is ignored

• Case 3: A > 0 AND B > 0 → Show error: xxx

  • If only one of A or B is hidden → Both conditions are still evaluated → Rule executes normally
  • If both A and B are hidden → Rule is ignored

• Case 4: (A > B) OR (C > D) → Show error: xxx

  • If either A or B is hidden → Process according to the above logic
  • If both A and B are hidden → Ignore condition (A > B) and evaluate (C > D)

---