Microsoft
Dataverse business rules vs plug-ins vs Power Automate: which should hold your logic?
Three ways to put logic into Dataverse, three very different trade-offs. A plain guide to choosing, and when none of them should own the decision.
The Condexa team · · 6 min read
Every Power Platform team has had this conversation. A new requirement lands: "orders over a certain value from a new customer need a second approver". Where should that logic live? A business rule, a plug-in or a Power Automate flow?
The honest answer is that each tool is good at something different, and the wrong choice costs you for years. Here is how to decide.
The three options at a glance
| Business rules | Plug-ins | Power Automate | |
|---|---|---|---|
| Who builds it | Makers | Developers | Makers and developers |
| Where it runs | Form, or server for the table | Inside the Dataverse pipeline | In a separate flow run |
| Best at | Simple field behaviour | Transactional, must-not-fail logic | Moving work between people and systems |
| Changing it | Quick, but gets messy | Code, test, release | Quick, but hard to govern at scale |
| Explaining a past decision | Not really | Only if you built logging | Run history, per flow |
Dataverse business rules
Business rules are the no-code option for a single table. They are ideal for making fields required, showing error messages and setting defaults.
Use them when:
- The logic is about one record and its own fields
- The behaviour is mainly for people using the form
- The conditions are few and unlikely to change often
Avoid them when the logic needs data from elsewhere, has tiers and exceptions, or must be reused by other systems. We cover this in more depth in Dynamics 365 business rules limitations.
Plug-ins
Plug-ins are .NET code registered against Dataverse events. They can run inside the same transaction as the save, so if the plug-in says no, the record is not saved.
Use them when:
- The logic must run for every write, whatever the source
- It must block the save, or change data in the same transaction
- Performance matters and you have developers to own it
The catch is ownership. Every change, even a threshold moving from 10,000 to 15,000, becomes a dev ticket, a test cycle and a release. The people who own the policy cannot read it, and they have to trust that the code matches what they asked for.
Power Automate
Cloud flows react to Dataverse events and are brilliant at orchestration: send the approval, wait for a response, update the record, post to Teams.
Use them when:
- The work is a sequence of steps across people and systems
- Timing is not critical to the save itself
- You want makers to own the process
Where flows struggle is as the home of the decision itself. A flow with twenty nested conditions and hard-coded values is as hard to read as code, and harder to test. Copies of the same logic appear in several flows, and they drift.
The question behind the question
Most debates about business rules vs plug-ins vs Power Automate are really about two different things mixed together:
- The process: what happens, in what order, and who gets told.
- The decision: what the answer is, given the facts.
Business rules, plug-ins and flows are all good at parts of the process. None of them is a comfortable home for a decision that finance, credit or procurement own and want to change themselves.
A cleaner split
A pattern that works well:
- Business rules keep the form tidy.
- A plug-in or a flow gathers the facts and asks for a decision.
- A decision service returns the answer and the reason.
- The plug-in or flow acts on the answer: approve, route, hold or notify.
With Condexa, the decision is a visual workflow the policy owner can read. Limits sit in lookup tables, which can read live from Dataverse. You test it with real examples before publishing, and the Active version answers over a REST API in milliseconds. A plug-in, a Power Automate flow or a Power App can all call the same decision, so there is one version of the truth.
When a rule changes, you publish a new version. No redeploy of the plug-in, no hunting through flows.
Quick decision guide
- One table, form behaviour, few conditions: business rule
- Must block the save, must run for every write: plug-in, calling a decision if the logic is policy
- People, approvals and notifications: Power Automate, calling a decision for the answer
- Policy that changes, needs explaining, or is used by more than one system: a decision service
Next steps
See how Condexa sits beside Dynamics 365 and Dataverse, or read our comparison of Condexa and Power Automate. If you would rather see it than read about it, book a 30-minute demo and bring one of your own rules.