Business Rule

---

When creating, viewing, or editing records, business rules can be set to modify field attributes (hidden, visible, read-only, editable, required) or make entire records non-editable. They can also compare field values and alert operators.

Examples

1. When scheduling interviews:

   For video interviews: display the meeting link,

   For on-site interviews: display the meeting room field.

   

2. When shipping a product:

   Prevent saving and alert the operator if the outbound quantity exceeds current inventory.

   

3. When a task's status is marked as "Finished":

   Make all fields non-editable.

   

Configuring Business Rules

Application administrators can configure business rules by navigating to the desired worksheet, then going to [More Settings] > [Business Rules].

Maximum of 100 business rules can be added per worksheet.

Components of Business Rules

Each business rule consists of:

• One or multiple conditions

• One or multiple actions

When the specified conditions are met, the corresponding actions will be executed.

Conditions

Supports setting either:

• A single condition, OR

• A group of conditions

Each condition contains three elements: Condition Field, Comparison, and Condition Value.

Fixed value: Example: For an "Interview Type" single-select field with 2 options, you would select a fixed value.

Field value/Dynamic value: Example: When comparing "Shipping Quantity" with "Inventory Quantity" - since inventory levels change dynamically, you should use the field value.

Actions

Available actions primarily include:

• Field interactions

• Field validations

Field Interaction

Field interactions support the following action types:

• Show field

• Hide field

• Set field as read-only

• Set field as required

• Set field as editable

• Set all fields as read-only

  • The "Set all fields as read-only" action takes effect after saving the record. Once activated, users cannot directly edit fields, though fields can still be populated through custom actions and workflows.

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)

---