Skip to main content
Back to the blog
Published on
min read
4
About
Ismael Baddich
Dynamics 365Power PlatformArchitecture

Plugin, Power Automate or business rule? Choosing the right tool in Dynamics 365

The same requirement can be built four different ways in Dynamics 365. A practical decision tree based on transactions, latency and the real cost of maintenance.

“When status changes to Approved, update the parent account.” That one-line requirement can be built as a business rule, a C# plugin, a Power Automate flow, or JavaScript on the form. All four work in a demo. One survives production.

Here’s how I decide.

The question that settles everything: is it transactional?

If the rule must always hold — an amount that must always reconcile, a status that can never be inconsistent — it has to run inside the database transaction. That leaves exactly one option: a synchronous plugin.

Everything else — Power Automate, JavaScript, async workflows — runs after the record is saved. There is a window, from milliseconds to minutes, during which the data is inconsistent. If that window is acceptable, you have choices. If it isn’t, you don’t.

Ask this first. It usually eliminates 80% of the options.

The decision tree

Is the rule about form display? → Business rule. Show/hide, make required, lock a field. No code, visible to functional consultants, survives upgrades. Don’t write JavaScript for this.

Must the rule hold even via the API? → Plugin. A data import, an integration, or a Power Apps user never touches your form. Any logic placed in JavaScript is bypassable by construction — that’s not validation, it’s interface convenience.

Does the rule call an external system? → Power Automate. Connectors save you writing, securing and maintaining an HTTP client inside a plugin. And a synchronous plugin calling a third-party service is a bad idea: you’re putting external network latency inside your transaction.

Is it bulk or scheduled work? → Scheduled Power Automate, or a console app depending on volume. Past a few thousand records, the plugin sandbox’s 2-minute limit becomes your enemy.

What Power Automate actually costs

Power Automate is often sold as the “no code, therefore cheaper” option. In maintenance, that’s rarely true.

What a flow costs you that code doesn’t:

  • Code review. A Git diff on a plugin reads in two minutes. A diff on a flow’s JSON definition is unreadable.
  • Cold debugging. Six months later, working out why a 40-action flow stopped triggering takes longer than a breakpoint in Visual Studio.
  • Service limits. They move, they’re per-environment, and they bite in production under load — not in test.

Power Automate excels when the logic is simple and the integration complex: three actions and a SharePoint connector. It degrades when the logic is complex and the integration simple: twenty nested conditions over Dataverse data. In that second case, write a plugin.

Plugins: three rules

When a plugin is the right call, three mistakes come up every time.

Register it on the right stage. PreValidation to block before anything happens, PreOperation to modify the target without a second call, PostOperation for anything needing the created record. A PostOperation that calls Update on its own target is a wasted round trip — and a potential infinite loop.

Filter the attributes. A plugin on Update with no attribute filter runs on every change to any field. On a busy entity, that’s thousands of pointless executions a day.

Never put a network call in a synchronous plugin. The sandbox cuts off at 2 minutes, and you hold the transaction the whole time. If an external system is slow or down, your users can’t save. Go asynchronous, or move it to Power Automate.

The summary table

Requirement Tool Why
Show / hide / make required Business rule No code, no maintenance
Guaranteed validation PreValidation plugin Cannot be bypassed
Calculation on the current record PreOperation plugin No second call
Calling an external system Power Automate Connectors, retry built in
Bulk processing Scheduled flow / console app No sandbox limit
Interface convenience JavaScript But never as validation

The real criterion

When choosing, ask a simpler question: who will maintain this in three years, and with what tools?

If the answer is “a functional consultant, without Visual Studio”, then a slightly imperfect business rule beats an elegant plugin nobody can change. If the answer is “the dev team, with Git and CI”, the plugin wins.

The right tool is rarely the most powerful one. It’s the one that matches the team who’ll live with it.

Related articles