Business logic for Canvas Apps: Plugins vs Flows vs WorkFlows

In the previous post I talked about using a “RetrieveMultiple” (+Update/Create) plugin to incorporate business logic into a Canvas App. And, of course, the very first question I got is “why using a plugin if you could use a Flow”?

It’s a fair question, and I figured I’d try to provide a fair answer. Have a feeling it might end up being not that clear-cut at all, though.

First of all, whatever business logic I was going to implement, it was always meant to work with CDS. I was not going to connect to other data sources there, so, from that standpoint, a Flow would not offer any benefits.

A plugin would have to be developed, of course, and that assumes there would have to be a “professional” developer. That would be another advantage of using a Flow where a “citizen” developer could actually do the job. Although, in reality this is a little more complicated, since, if you look at the classic workflows and compare them with plugins and Flows from the development effort perspective, I think the comparison would go like this:

*That’s if we leave custom workflow activities out of this, of course.

Of course plugins are way more on the development side than Flows, but Flows seem to require more effort from the “citizen” developers than classic workfows.

Either way, in my case there would be a “professional” developer to maintain the plugins, so I was not too concerned about that part.

Now, with the Flows being stripped off their two main advantages over the plugins (in this particular situation), let’s see why a plugin might be a better option:

• When compared to the classic “code” development, no-code development will always be limited no matter how great the tools are. To some extent it’s fine, but, then, once the logic becomes really complicated, it’s actually much easier to maintain it in code, since it’s a lot more concise there
• Plugins are offering better control of where and how they will start. Actually, neither the Canvas App, nor the model driven app have to worry about whether the plugin will start or not – it will happen automatically
• Flows are asynchronous, and plugins can be both synchronous and asynchronous. That’s not always a big deal, but can be useful every now and then
• Plugins can be added to the solutions and moved between the environments. The same is true for the Flows; although, I believe we still need to reset Flow connections in the target environment after importing the Flow there. Plugins will just start to work
• When developing a plugin, we can rely on the usual source control merge tools since plugins are all about the source code

In other words, the reason I went with a plugin in case with the inspection canvas application is, basically, that I did not need those advantages Flows can offer, and, as such, it seemed a plugin would fit better.

Hope it makes sense.