Dataverse business rule

What is a Dataverse business rule?

A Dataverse business rule is a way to apply logic to a table without writing JavaScript or building a plug-in. You draw the rule in a visual designer, and it becomes part of the table's metadata inside Microsoft Dataverse.

A single rule can set or clear a column value, set a default, make a column required, show an error and stop a save, and on a form it can also show, hide, lock or unlock a column or show a recommendation. Which of those actions you get depends on the scope you pick.

Because the rule lives with the table rather than inside one screen, the same logic can apply everywhere that table is used. That is what makes it different from a script you attach to a single form.

Conditions and actions

Every rule starts with a condition. The condition compares column values or checks whether a column contains data, for example whether Status equals Closed.

From there the rule branches. Actions on the true branch run when the condition is met, and actions on the false branch run when it is not. A rule might make End date required as soon as Status becomes Closed, and drop that requirement again when it changes back.

Keep each rule small and name it after the business intent it expresses. A tangle of overlapping rules on one table becomes hard to predict and harder to test.

Scope decides where a rule runs

Scope is the setting that matters most, because it decides how far the rule reaches.

Table scope runs supported logic on all forms and on the server. Server-side means validation applies to other Dataverse clients and to writes that come through the API, not just to the form a person is looking at.

All Forms applies the rule to the model-driven forms where it is available.

Specific form limits the rule to that one form.

Some actions only make sense on a form. Hiding, locking or recommending a column has no visual effect on the server, so those actions are ignored when a rule runs server-side. A canvas app also supports fewer actions than a model-driven form, which is why the table scope is the one to use when a canvas app needs the rule.

Worked example: closing a case

A team handles support cases. When a case moves to Closed, Resolution date must be filled in and Closure reason cannot be empty.

A business rule with table scope checks both columns and shows an error when either is missing. The check then holds whether someone edits the record on a model-driven form, in a canvas app, or through an integration that writes over the API. A second, form-only rule can reveal extra fields on the case form once the status changes, purely to guide the person filling it in.

If the same check had to count related approvals or call an external register, a business rule would no longer fit. That is server logic, and it belongs in a plug-in or a flow.

Business rule versus Power Fx, plug-in and flow

Power Fx drives properties and behaviour inside a canvas app and sits close to the interface. It is a good fit for in-app logic, but it does not protect data that another client can write directly. Treat an interface formula as convenience, not as the last line of defence.

A plug-in gives you programmable server logic, access to the execution context and transactional control. It needs developer skills and careful attention to performance, so it earns its place only when the logic is genuinely beyond a rule.

A flow in Power Automate suits process steps, connector actions and follow-up that can happen asynchronously. It is less suited to stopping an invalid write the instant it happens.

A business rule sits in the middle for simple field logic. Do not force loops, complex queries or integration into a mechanism that was not built for them.

What to watch out for with Dataverse business rules

Not every column type is supported. Business rules do not work with multi-select choice, file or language columns, and editable grids support only a subset of actions. Test the rule in each app where the table appears, not only in the designer.

Deactivate before you edit. You have to turn a rule off to change it, then validate and reactivate the new version. Include rules in your solutions so they move cleanly between development, test and production.

Rules can compete with each other. Several business rules, form scripts and plug-ins can all touch the same column. Write down the source and order of each piece of logic so two of them do not quietly overwrite one another.

Volume affects performance. Power Platform supports up to 150 business rules on a single table before performance starts to suffer, counting both the client-side and server-side rules. Long before that limit, a table with dozens of rules is a sign the logic wants to move somewhere it can be tested properly.