A new requirement lands: "When an opportunity's amount exceeds 50,000, flag it for legal review and notify the deal desk." Every developer who has worked in Dataverse for more than six months has four places they could put this logic. Half the arguments on a mature team are about which place is the right one.

Here is the decision tree we run, with the cost, latency and maintainability trade-offs that actually play out in production.

The four options

Business Rule. Declarative, runs client-side in model-driven forms. Can set field values, show/hide fields, set requirement levels. Cannot call other services.

Power Automate cloud flow. Asynchronous, server-side. Triggered by Dataverse table events (create, update, delete). Can call any connector - Dataverse itself, SharePoint, HTTP endpoints, anything. Visual designer.

Classic workflow. Legacy equivalent of Power Automate, lives inside Dataverse. Still supported for some patterns (synchronous custom actions, rollup field recalculation) but Microsoft's direction is Power Automate.

Plugin (custom code). C# class that registers against the Dataverse execution pipeline. Runs server-side, can be synchronous (inside the original database transaction) or asynchronous. Full .NET, full Dataverse SDK.

The decision tree

Where each one breaks

Business Rules break when:

• You need to run on API writes (they only fire in model-driven forms)
• You need conditional logic beyond AND/OR on field values
• You need to call external services

In practice, Business Rules are useful for exactly one pattern: "when field A has value X, show/require field B." Anything more complex becomes unreadable fast.

Power Automate breaks when:

• You need to block a save on validation failure (Power Automate is always async from a Dataverse write's perspective)
• You need sub-second latency (typical cold-start latency is 3-10 seconds for a new flow run)
• You are in a high-volume scenario - flow runs cost against your per-seat or per-flow licensing

The licensing trap is real. A plugin on a write trigger fires for free. A Power Automate flow on the same trigger consumes one run per event. A Dataverse table that sees 500,000 writes per day under a per-flow-plan license ($100/month for 3 flows) is fine; under per-user-plan licensing, the math needs checking.

Plugins break when:

• You need visual configurability for non-developers to maintain
• You call external HTTP endpoints from sync code (2-minute plugin timeout + slow HTTP = failures)
• You want a non-developer to understand what it does by reading it

Plugins are the right hammer for high-volume, low-latency, Dataverse-internal logic. They are the wrong hammer when the "requirements" column in the ticket is a paragraph a business analyst will revise weekly.

Classic workflows we avoid for new work. Microsoft's documentation repeatedly nudges toward Power Automate, and we take the hint.

Case: the opportunity-flagging requirement

Back to "When an opportunity's amount exceeds 50,000, flag for legal review and notify deal desk."

Decompose into two actions:

1. Flag for legal review - a boolean field acme_requires_legal_review set to true. This is a row modification, needs to run on every save (UI or API), should block the save from proceeding if other logic depends on the flag.Plugin, synchronous, pre-operation. Ten lines of C# in a well-named step.
2. Notify deal desk - send an email or Teams message. Not time-sensitive (hours of latency fine), needs to integrate with Outlook or Teams connectors.Power Automate cloud flow, triggered on update of acme_requires_legal_review = true.

Two tools, one requirement. The split falls out of the "does it modify the row" and "does it integrate with non-Dataverse" questions.

Teams who pick one tool for everything end up with either:

• A 40-step Power Automate flow that does both, times out occasionally, and breaks silently when the notification connector has a bad day
• A plugin that sends emails via System.Net.Mail, fails auth against Exchange Online, and exposes SMTP credentials in code

Two targeted tools working together beats one tool stretched past its good use.

The review we run before merging

On every pull request that adds logic, the reviewer asks four questions:

1. Is this the right tool? (Walk through the decision tree above.)
2. If it is a plugin, is it in the right pipeline stage? (Pre-validation vs pre-operation vs post-operation - each has different semantics.)
3. If it is a flow, is it idempotent? (Retries happen; a flow that double-charges a customer on retry is a problem.)
4. Is the logic named and documented so a new team member can find it?

Question 4 is the one teams skip most. Dataverse gives you four places to put logic; unless a newcomer can find which one you chose, they will add their own in a fifth place.