Dataverse dilemma: should it be a flow or should it be a plugin?

When it comes to implementing business logic In the Dataverse environments, we have a few valid options:

• Cloud flows
• Plugins
• Classic workflows

Yes, classic workflows is not at the top of our minds these days, but, with no Flow alternative to the real-time workflows, I don’t see them going away easily yet.

However, for all other purposes Power Automate flows are a superior technology(to the workflows), so this is why classic workflows did not even show up in the title of this blog.

When it comes to the plugins and Flows, the question seems to have a simple answer if you ask a non-developer. Since, of course, you do need to know how to develop plugins, and, in general, it’s easier to jump into Flows development instead.

That said, I’ve been developing plugins for a long time, and I did do other development every now and then (less so once I switched to Dynamics, to be fair), but, learning Power Automate to the point where I felt comfortable with it took quite a bit of time. There are little tricks that eventually make you productive, and you need to learn them as you go.

Yet there are still areas of the flows where I feel a bit dizzy. As in, how do we handle errors so we can report on those errors properly? How do we make multiple updates consistent if there is no concept of transactions? Those are just two which are always at the top of my mind, but there are smaller ones, too (as in, “what’s the exact syntax for that expression I need to write here?”)

Of course, flows are great for integrations. Forget about Dataverse for a second – there are hundreds of connectors to other systems. It might be really time-consuming to implement those integrations from scratch in the plugins, so, if there is a connector in Power Automate already, creating a Power Automate flow is always my first choice in such cases.

However, what if we are, mostly, focused on the Dataverse?

Is it still better to use Flows, or is it better to use plugins? From what I’ve seen so far, the answer seem to depend on the business logic complexity, but, also, it depends on the team’s tolerance towards pro-dev:

From the complexity perspective, the inherent problem of the flows is that they are no-code.

How come it’s a problem? Well, Flows just do not support classic concepts or tools of code development – there are no functions, there is no object-oriented programming, error handling is not as simple, and there is even no way to easily “refactor” the flow (for example, to do find and replace). Besides, usual code is much more concise when looking at it in the dev tools (when compared to the Flow in the flow designer), which makes it easier to grasp what’s happening in the code, especially as the code/flow starts growing.

I’ve seen it a bunch of times already that we would start with a flow (easy to start, yet it seems to be the preferred way), and, then, that Flow would grow out of proportions quickly, so we’d either have to start using child flows(which is not necessarily helping that much), or we’d have to give up on the flow and create a plugin instead.

And remember this is all in the context of the Dataverse business logic – as soon as we throw in some kind of integration requirement (even with Sharepoint) things can easily change, since this is where Flows approach gets a significant boost.

Then, of course, there is that other aspect of the decision-making process.

Are there enough developers who can develop plugins, and, also, do we want to lock into that mode of development? This, of course, is the main reason Flows showed up in the first place – democratizing development and making it less dependent on the pro-dev team members. That’s the y-axe on the diagram above: team tolerance towards pro-dev development. It’s not, necessarily, team experience that matters. It’s, also, where the management has to commit and say that “We are fine with having plugin developers on the team”, and that would be for both initial development and ongoing maintenance.

My personal feeling is that, no matter how good Flows are for relatively simple tasks, business logic complexity will still drive teams towards plugin development as soon as they have access to the proper “dev resources”, though I might be wrong – time will show.

PS. There is, also, a mixed model. We can create Custom API-s (that would be plugin development, basically), and we can use custom API-s from our flows. We can also create flows and call them from our plugins (using http triggers, for example). The former seems to be how things should be mixed, but the latter is also doable. And, still, in this mixed model the need to dev resources on the team is not going away, so nothing changes for the diagram above.