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.
So far, I agree with you Alex.
There are some complexities / defaults of Flow that make me think twice before using one.
1) it seems you get all attributes when doing a Get Record which may not be ideal if you only need 1 or 2.
2) I have not found a way to create templates of flows. Often plugins are created to do similar steps across multiple entities. With Flow I have yet to find an easy way to template that.
3) plugins (in a properly structured VS project) can be traced / identified and updated entities change or processes change. Flow still seems to be a bit disjointed from a monitoring / upgrade standpoint.
I think there are lots of good places for Flow. I also think there are good places for a well tuned, we’ll instrumented Plug-in, though I probably have yet to write one 😉
Well, as for the plugins, not sure I have managed to pull off a lot of those well-structured and well-instrumented ones either?
Can’t yet suggest anything for flow templates…