15.1 Configuring Business Rules

Business rules are the fastest no-code way to enforce data quality and form behavior in Microsoft Dataverse, and the AB-410 exam treats them as a core tool in the Build business application logic and automation domain. A business rule combines conditions (if-tests on column values) with actions (what happens when the test passes or fails), all authored in a drag-and-drop designer — no JavaScript, no plug-ins.

The Business Rule Designer

You create rules at make.powerapps.com either from a table (select the table, then the Business rules tab, then Add business rule) or directly inside the model-driven form designer (left pane > Business rules > New business rule). The designer opens with a single Condition component already on the canvas. You drag additional components from the Components tab onto plus signs in the flow: a plus sign next to a check mark runs the component when the condition is true, and a plus sign next to an X runs it when the condition is false — that X branch is your else branch.

Each condition holds one or more clauses joined by AND or OR; you add a clause by selecting New on the condition's Properties tab. Conditions test a column against a value, against another column, or against a formula. The designer builds the equivalent rule code at the bottom of the window as you work, which is a useful sanity check on exactly what will evaluate.

Scenario

A maker at a field-service company builds a rule on the Work Order table: if Priority equals Emergency, then set Response SLA (hours) to a default of 4, make Supervisor Approval business required, and show the Escalation Reason column. If Priority is anything else (the else branch), the rule clears the required flag and hides Escalation Reason again. Every piece of that is one condition plus four actions on the true branch and two on the false branch — the exam loves asking you to map a written scenario like this onto condition-and-action components.

Scope: Where the Rule Runs

Scope is the single most exam-tested property of a business rule, because it decides where the logic executes.

Rules scoped to a form fire when the form loads and when a referenced column's value changes on that form. Rules scoped to the table evaluate when the row is saved, no matter which client or integration wrote the data. Form-only actions such as show/hide or lock/unlock are simply ignored when a table-scoped rule runs server-side, while a Show Error Message action becomes a hard validation: it blocks the save and rolls back the database transaction, even when the write came from an API call.

Exam trap: The classic wrong answer is "the rule works in the app but does nothing when rows arrive from an import or a flow." The fix is never to rewrite the rule — it is to change the scope from a form to the table. The mirror-image trap: a maker wants a rule to apply to every form, chooses All Forms, and expects it to govern canvas apps and integrations. All Forms is still client-side; only table scope reaches the server.

Actions, Activation, and Limitations

The eight actions you can drag onto a rule are:

• Set visibility — show or hide a column on the form
• Set business required — toggle the red asterisk that blocks saving an empty value
• Set default value — fill a column when the condition is met
• Set field value — write a hard-coded value, another column's value, or a simple formula result
• Lock/unlock — make a column read-only or editable again (rules can even unlock columns on a read-only form)
• Show error message — validation text that stops the save
• Recommendation — a light-bulb prompt suggesting a value the user can Apply or dismiss; this action exists only in business rules

Before a rule does anything, you must select Save and then Activate on the action bar. A saved-but-deactivated rule is inert — and you must deactivate a rule before you can edit it or change its scope. Use Validate before activating to catch missing references.

Known limits the exam tests

• Rules act only on columns of the current table and, for form-scoped rules, only columns present on the form — a referenced column missing from the form is the most common reason a rule silently does not fire.
• No cross-table access: a rule cannot read or update related parent or child rows.
• Formulas are limited to addition, subtraction, multiplication, or division of two columns — no aggregation, date math beyond simple arithmetic, or string functions.
• Rules do not run on the form's save event; they fire on load and on column change.
• Performance guidance: keep it under roughly 150 business rules per table.

When a requirement exceeds these limits — cross-table lookups, rich expressions, loops, or automation after save — choose Power Fx (low-code formulas in canvas apps and modern commanding), a Power Automate flow, or a plug-in instead. Picking the right tool for a given scenario is a recurring AB-410 question pattern.