A developer's opinion: Microsoft Flow for Dynamics 365 Customer Engagement

April 2 2019

Rumors have been spreading about no-code and low-code being the way forward in the world of Microsoft Dynamics 365 Customer Engagement and the Common Data Service. To my knowledge, this is the result of the marketing surrounding Flow, which is promoted as one of the three pillars of the Power Platform, the two others being PowerApps and Power BI.

In my eyes, the difference between Flow and the native CRM workflow  ("Workflow") we know today is the over 200 connectors that allow flows to work with a large variety of data. When I see this, I see the same advertisement that my cable company gives me with 500+ channels. I fear that I will only end up using a small subset of the connectors in Flow. Nonetheless, this is also the feature I admire the most with Flow. It is not trivial to combine data from different products using code.

So, when do we use flows? When you try to meet a business requirement, you must always consider what this requirement will evolve into in two weeks, six months or a year from now. I have only chosen a Workflow once or twice in my life, and that was to send emails. Once you choose to implement a workflow, calculated field or any other solution, it is hard to switch. Therefore, I always pick the most powerful option, which ends up being code.

By placing your logic in code, you make your system more maintainable. You open your solution to the powers of DevOps and strongly-typed development. You will no longer be prone to errors related to removing fields from forms or the removal of option set values, just to name a few.

Flows are declarative, which means they operate on a higher-level than code. This also means they are less expressive. If I had to convert the codebases of over 50,000 lines of plugin code to flows, then it would be unmaintainable. My mind takes me back to the horrors of giant Excel sheets that businesses used to rely upon for their core business.

About Magnus Gether Sørensen

As a Computer Scientist and Engineer, that loves to improve the way he works, Magnus pushes the limitations of the XRM SDK daily. His goal as a developer for XRM is to make the developer experience easier for his colleagues. Magnus does this by creating developer tools, which has given him the nickname XRM Tooling Wizard. Magnus’ goal is to bring best practices from both the academic- and real world into the world of Business Applications - and where else applicable. See his work on GitHub https://github.com/delegateas

Twitter: @xrmwizard

More about Magnus Gether Sørensen


larmar's picture

"Therefore, I always pick the most powerful option, which ends up being code."
I do not agree at all. Why shall we always use the most comprehensive way for solving a business requirement? Understand the process requirement, try to figure out what is coming next and select the implementation approach which fits best. Sometimes it can be code but very often a flow can also be a solution. I do not like these kind of general statements.

"What will happen when that power user leaves the company at some point?"
My question: what happens when the developer leaves the company who developed a plugin or whatever nobody knows?

From my point of view it all comes together to the question of architecture. CRM always required a lot of thinking about architecture and all the new technical possibilities we have requires it the same way.
Of course you can be maybe faster when implementing a business requirement with flows but it will always fail at the end when the architecture is not well thought. And here I mean ownership, monitoring and things like that.