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

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.