Business rules in Dataverse

Business rules in Dataverse give makers a graphical, no-code way to add field-level logic to forms — set field defaults conditionally, lock fields based on status, show validation errors, surface recommendations. They run on the client and on the server, so the same rule enforces both during interactive editing and at API write. Used well, they replace small JavaScript snippets and simple plug-ins with declarative configuration; used badly, they multiply unmaintainable spaghetti.

The model. A business rule has:

• Scope — Entity (runs everywhere including the server) or specific form(s).
• Trigger — when the rule evaluates: on form load, on field change, on save.
• Condition — a tree of AND/OR logic on field values.
• Actions — what happens when the condition is met:
  • Set field value
  • Set business required (Optional, Recommended, Required)
  • Set visibility
  • Lock or unlock field
  • Show error message
  • Set default value
  • Recommendation (suggest a value with one-click acceptance)

Server-side enforcement. With Scope = Entity, the rule runs server-side as well as client-side. A "Status must be Open before activation" rule enforced server-side blocks API writes that would bypass the form. This makes business rules genuinely enforcing, not just guidance.

Common patterns.

• Conditional required fields. "If Type = Customer, then Tax ID is required."
• Mutual exclusivity. "If Has Insurance = Yes, show Insurance Provider; if No, hide it."
• Validation. "If Discount > 20%, show error: 'Discount above policy maximum, requires approval'."
• Defaulting. "If Industry = Manufacturing, default Payment Terms = Net 30."
• Locking after status change. "If Status = Won, lock Estimated Revenue and Close Date."
• Recommendations. "If Customer Type = Enterprise, recommend setting Account Manager = X."

Limits.

• Single-table only. Business rules reference fields on the same table; they can't read from related tables. For cross-table logic, use plug-ins or Power Automate flows.
• No external calls. Rules can't call APIs, services, or external systems. Pure declarative logic only.
• No loops or complex iteration. The rule is a flat condition-and-action structure.
• Activation order. Multiple business rules on the same table fire in their activation order. Conflicts produce unpredictable behaviour.
• Performance. Heavily nested rules with many actions slow form load. Audit if forms feel sluggish.

Choosing business rules vs other mechanisms.

• Business rule — simple field-level logic on one table; enforced both client and server.
• JavaScript / Client API — complex UI logic, calls to other tables, dynamic web-resource manipulation. Client-side only.
• Power Automate flow — multi-step logic, cross-table updates, external system calls. Server-side, asynchronous typically.
• Plug-in — complex transactional logic, performance-critical real-time, cross-table validation. Server-side, synchronous or async.

Lifecycle and version control. Business rules live inside solutions; they version, export, and import like any other component. They show up in solution layers and managed-vs-unmanaged contexts.

Editor UX. The business rule designer is graphical — drag and drop conditions, drag and drop actions, connect them. Suitable for citizen developers. Pro developers can switch to the JSON view for finer control.

Debugging. When a business rule misbehaves, debugging is mostly inspection:

• Browser developer tools to see client-side evaluation.
• Audit logs for server-side firings.
• Manual test data to walk through the rule.

There's no breakpoint debugger; the design has to be simple enough to reason about by reading.

Common pitfalls.

• Conflicting rules — two rules both touching the same field with different conditions; the last one wins, often unpredictably.
• Rule logic in too many places — same field affected by a business rule, a JavaScript handler, and a server-side plug-in; debugging becomes a nightmare. Centralise.
• Over-restrictive rules — locking a field "until status is X" without considering edge cases prevents legitimate user work.
• Stale rules — original rule fires for a long-gone process; new users see strange behaviour and don't know why.

Operational discipline. Document every business rule's purpose in its description field. Audit annually — retire what's not used; consolidate overlapping rules. Don't let business rules accrete without governance.