12.2 Business Rules: Scope & Actions

Business Rules: Scope & Actions

In Microsoft Dataverse, Business Rules provide a powerful, visual, no-code mechanism to implement form logic, enforce data integrity, and automate field-level interactions. Before business rules were introduced, developers had to write custom JavaScript client-side scripts to show or hide fields, calculate values, or lock form inputs. Business rules allow functional consultants to implement these requirements declaratively through a visual drag-and-drop designer, with the added capability of enforcing critical rules on the server side across all data entry channels.

---

1. Business Rules Architecture & Visual Designer

A Business Rule consists of Conditions (the logical triggers) and Actions (the resulting behaviors). When a record is loaded or when a monitored field changes, Dataverse evaluates the condition rules and executes the appropriate True or False action branches.

+-----------------------------------------------------------------------------------+
|                         BUSINESS RULE LOGICAL STRUCTURE                           |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | CONDITION: IF [Field] [Operator: Equals / Contains / etc.] [Value / Field]   |  |
|  |            AND / OR [Additional Condition Rule]                             |  |
|  +-----------------------------------------------------------------------------+  |
|          |                                            |                           |
|     (Evaluates TRUE)                             (Evaluates FALSE)                |
|          |                                            |                           |
|          v                                            v                           |
|  +-----------------------------+             +-----------------------------+      |
|  | TRUE ACTION BRANCH          |             | FALSE ACTION BRANCH         |      |
|  | - Set Visibility: Show      |             | - Set Visibility: Hide      |      |
|  | - Set Business Required     |             | - Set Optional              |      |
|  | - Lock Field (Read-only)    |             | - Unlock Field (Editable)   |      |
|  | - Set Field Value / Default |             | - Clear Field Value         |      |
|  | - Show Error Message        |             | - Show Recommendation       |      |
|  +-----------------------------+             +-----------------------------+      |
+-----------------------------------------------------------------------------------+

Condition Logic

• Condition Rules: Each condition evaluates one or more column attributes against static literal values, system values, or other columns on the same table.
• Logical Operators: Conditions can be combined using AND or OR logic. Within a single condition component, all rules must use the same operator (all ANDs or all ORs).
• Branching Limit: A single Business Rule supports a maximum of 10 nested IF-ELSE condition branches.

---

2. Business Rule Scope: Client vs. Server Execution

The most critical architectural setting on a Business Rule is its Scope. The Scope determines whether the rule executes strictly within the user's web browser, or if it also executes on the Dataverse server during programmatic data operations.

+-----------------------------------------------------------------------------------+
|                        BUSINESS RULE SCOPE ARCHITECTURE                           |
|                                                                                   |
|  [SCOPE: SPECIFIC FORM]  ---> Client-side only; executes ONLY on selected Form    |
|  [SCOPE: ALL FORMS]      ---> Client-side only; executes on ALL Model-Driven Forms|
|                                                                                   |
|  [SCOPE: ENTITY / TABLE] ---> DUAL EXECUTION (Client + Server):                   |
|          |                                                                        |
|          +---> 1. CLIENT-SIDE: Model-Driven Forms + Canvas Apps (Power Fx)        |
|          |                                                                        |
|          +---> 2. SERVER-SIDE: Dataverse Transaction Pipeline                     |
|                - Bulk Data Imports (Excel / CSV)                                  |
|                - Web API / OData Programmatic Calls                               |
|                - Power Automate Cloud Flow create/update actions                  |
|                - Classic Workflows & Plug-ins                                     |
+-----------------------------------------------------------------------------------+

Scope Setting Comparison

1. Specific Form (e.g., "Account Main Form" or "Quick Create"):
   • Execution Context: Client-side only.
   • Behavior: The business rule runs only when the user opens or edits data using that specific form in a model-driven app. It does not run on other forms, quick create forms, canvas apps, or server transactions.
2. All Forms:
   • Execution Context: Client-side only.
   • Behavior: The business rule runs across all Main forms and Quick Create forms for that table within model-driven apps. However, it does not execute on server-side operations.
3. Entity (or Table):
   • Execution Context: Dual Execution (Client-side AND Server-side).
   • Behavior: The rule executes client-side on all model-driven forms and canvas apps, AND executes server-side within the Dataverse pipeline whenever a record is created or updated through any channel (Data Imports, Dataflows, Web API calls, Power Automate Cloud Flows, or custom code).

Server-Side Action Compatibility on Entity Scope

When a Business Rule is configured with Entity (Table) scope, not all actions can execute on the server. Because the server has no user interface (no screen, fields, or buttons), UI-specific actions are ignored during server transactions:

[!IMPORTANT] Entity Scope Server-Side Enforcement: If an organization requires that a validation rule (such as 'Discount cannot exceed 20%') be enforced regardless of whether records are created via a model-driven form, an Excel data import, or an automated Cloud Flow, the Business Rule scope MUST be set to Entity / Table.

---

3. Business Rule Action Catalog

Dataverse Business Rules support eight distinct action types:

+-----------------------------------------------------------------------------+
|                        BUSINESS RULE ACTION CATALOG                         |
|                                                                             |
|   1. SET FIELD VALUE       ---> Assigns a static value, field value, or calc|
|   2. CLEAR FIELD VALUE     ---> Sets the target column to null              |
|   3. SET BUSINESS REQUIRED ---> Toggles field between Required and Optional |
|   4. SET VISIBILITY        ---> Shows or hides a column on the form UI      |
|   5. LOCK / UNLOCK         ---> Makes a column Read-Only or Editable        |
|   6. SET DEFAULT VALUE     ---> Pre-populates column on new record creation |
|   7. SHOW ERROR MESSAGE    ---> Displays error text and blocks form save    |
|   8. RECOMMENDATION        ---> Non-blocking suggestion with 'Apply' button |
+-----------------------------------------------------------------------------+

Action Mechanics & Use Cases

1. Set Field Value: Populates a column with a static literal, another column's value from the same table, or a simple mathematical formula (e.g., Price * Quantity).
2. Clear Field Value: Resets the target column value to null. Commonly used in False branches when a dependent field is hidden.
3. Set Business Required: Dynamically changes the requirement level of a column to Business Required or Optional based on context (e.g., if 'Preferred Contact Method' is Email, make 'Email Address' Business Required).
4. Set Visibility: Shows or hides fields, sections, or tabs dynamically. Hiding irrelevant fields streamlines the form layout and reduces user cognitive load.
5. Lock / Unlock Field: Changes a field to read-only (locked) or editable (unlocked). Often used to prevent users from modifying calculated fields or locked contract terms.
6. Set Default Value: Automatically applies a predefined value when a brand-new row is initialized. Unlike Set Field Value, users can freely overwrite a default value unless the field is also locked.
7. Show Error Message: Binds a warning/error notification to a specific field or to the form header. The message displays red error text and blocks the user from saving the record until the invalid condition is corrected.
8. Recommendation: An interactive, advisory prompt. Instead of forcing a change or blocking the user, a lightbulb icon appears beside the field. When clicked, it displays a pop-over containing a custom Title, descriptive Details, and an Apply button. If the user clicks Apply, the configured sub-actions (e.g., updating a field value) execute immediately.

---

4. Execution Lifecycle, JavaScript Interactions & Platform Limitations

To troubleshoot business rules effectively and architect cohesive solutions, consultants must understand how business rules interact with other form components and platform limitations.

Client-Side Execution Order

When a model-driven form renders and processes user input, Dataverse follows a strict execution lifecycle:

[Form Open] ---> 1. JavaScript OnLoad Events Execute
                    | 
                    v
                 2. Business Rules Evaluate & Execute
                    | 
[Field Change]-> 3. JavaScript OnChange Events Execute
                    | 
                    v
                 4. Business Rules Re-evaluate & Execute
                    | 
[Form Save] ---> 5. Client Validation (Required fields & Error Messages checked)
                    | 
                    v
                 6. JavaScript OnSave Events Execute
                    | 
                    v
                 7. Server Pipeline Commit (Entity-scope Business Rules run)

[!NOTE] Business Rules vs. JavaScript Order: Business Rules execute after JavaScript OnLoad and OnChange event handlers. If a JavaScript function sets a field value, any Business Rule monitoring that field immediately re-evaluates and can override the JavaScript change.

Hard Platform Boundaries & Limitations

• No Child Entity Queries: Business Rules can only evaluate and act upon columns belonging to the current record. They cannot query across 1:N or N:N child relationships (e.g., an Account business rule cannot check child Contact counts or aggregate child Invoice balances).
• No External API Calls: Business Rules cannot call external REST endpoints, Azure functions, or webhooks.
• Fields Must Exist on Form (for Client Rules): For a client-side business rule (Form or All Forms scope) to evaluate a column or execute an action, that column must be present on the form. If a required column is omitted from the form layout, the client-side rule will not fire for that column.
• Cannot Trigger on Record Read: Business Rules execute only on form load, column change, or server save; they do not execute when a user simply browses views or reads data without opening a form or submitting a transaction.