Business rules

What it does

A declarative condition-and-action rule attached to a table, built in a drag-and-drop designer. Every rule starts with a condition; the actions available are setting and clearing column values, setting requirement levels, showing and hiding columns, enabling and disabling columns, showing a validation error, and business recommendations.

Key facts

Scope is chosen per rule: Entity (model-driven forms and server), All Forms (model-driven forms only), or a single named form. Canvas apps only honour rules scoped to the table.
Show/hide, enable/disable and business recommendations don't work in canvas apps. Recommendations also can't be created for table-based view pages, and editable subgrids don't support business rules at all.
Multi-select Choices, File and Language columns aren't supported. Text, number, choice, date, lookup, owner and image are.
Microsoft's stated ceiling is 150 business rules per table, counting both the client-side JavaScript and the server-side XAML that's generated as synchronous plug-ins. Beyond that you should expect performance degradation.
You must deactivate a rule to edit it, and activation happens from solution explorer, not from the designer.
Business rules run before an onLoad script and don't react to values that script sets afterwards.
Activating or changing a rule doesn't reprocess existing rows. Nothing is retrospective.
DateOnly columns are evaluated in UTC regardless of the user's time zone unless you set the column to Time Zone Independent.

When to use / skip

Use them for form-level validation and simple field behaviour that a functional consultant needs to own and change without a developer in the loop — required-when-X, hide-unless-Y, block-save-with-a-message. Skip them the moment the logic needs to read related rows, loop, call anything, or make a decision more complex than a handful of ANDs, because the designer will fight you and the result will be unreadable in six months. If you find yourself building your fifteenth rule on one table, you've picked the wrong tool: consolidate into a single form script or move the logic server-side.

Configuration decisions

Scope, and whether the rule needs to hold on the server as well as in the form — table scope is the only one that also protects API and integration writes.
Whether validation belongs here or in a plug-in, given that anything scoped to a form is trivially bypassed by the Web API.
Whether the error messages need translating, since each one generates a label that has to go through the translation export/import cycle.
How many rules one table is allowed before you move to script, and who polices that.
Whether recommendations are worth it at all, given they don't work in canvas apps and users routinely ignore them.

Gotchas

A rule silently does nothing if a column it references isn't on the form. No error, no warning — it just never fires. This is the single most common "my business rule is broken" call.
The documentation contradicts itself on where rules run. The FAQ on the same page states that business rules run on clients and aren't executed inside Dataverse, while the scope table says table scope covers "model-driven app forms and server" and the performance section describes server-side XAML generated as synchronous plug-ins. Treat table scope as running server-side, and test it rather than trusting either statement.
Composite attributes like Full Name aren't supported in Unified Interface. Use the constituent columns instead.
Rules generate synchronous plug-ins behind the scenes, so a table stuffed with them slows down every write, not just the form.

Consultant notes

Sell business rules as maintainable form logic, not as validation. If the client believes a business rule secures the data, they'll be surprised the first time an integration writes a row that breaks every rule at once.
Agree a naming convention on day one. Twelve rules called "Business Rule 1" through "Business Rule 12" is a real thing you will inherit.
Warn the client that changing a rule doesn't clean up existing data, so any tightening of validation needs a separate data remediation conversation.
If you're heading past a dozen rules on a core table, raise it early. Retrofitting them into a single script after go-live is a rewrite, not a tidy-up.

Worth another look if the client moves to canvas apps, or if anyone starts writing to the table through the API.