Power Apps and Power Platform have muddied the waters?

Have Power Apps and Power Platform muddied the waters?

That may seem like a peculiar comment from me – a Microsoft Certified Trainer (MCT), Business Applications Most Valuable Professional (MVP) and someone who loves helping people achieve business success with Microsoft Dynamics 365.

I think that Power Apps has certainly added a layer of confusion for people selecting team members for a Dynamics 365 project. Let me explain.

Twenty years ago, I could have had a conversation with you about implementing Microsoft CRM. This would have covered the out-of-the-box functionality and what we needed to achieve using configuration or customisation. Configuration is generally the changes that you can make using the internal tools, and customisation is the code that we use to create changes when configuration is not enough. Up until about five years ago, this conversation only changed because of the exponential increases in the out-of-the-box functionality and the massive improvements to what we could do with configuration.

Then Power Platform arrived, and specifically Power Automate. Certainly, Power Platform has given us yet another boost to the power that we can provide to our clients. However, and this is where I believe that it is has muddied the waters, its power extends beyond the Power Apps. Power Apps are the Microsoft first party apps (developed by Microsoft, rather than an ISV) for Sales, Marketing, Customer Service and Field Service. The Power Platform includes the Power Apps, and also Power Pages, (for portals and web pages) Power Virtual Agents (for bots to help your customers) Power BI (for reports and dashboards) and Power Automate.

Power Platform now extends to include non-Microsoft tools, Microsoft Office, SharePoint and far more. Why this is a problem for people selecting team members for a Dynamics 365 project is because it is now very easy to end up with people with almost no knowledge of Power Apps making decisions about how Power Apps should be configured to meet a client’s needs!

Only today, I spoke with a colleague who has been handed a knotty problem to sort out. This problem appears to be caused by a Power Platform person with no knowledge of Power Apps – let’s call him Noko. Noko has configured the Business Process flow using javascript! essentially because the names of the stages were incorrect. It seems that everything the client required could have been met using the standard Opportunity Business Process flow, with some renamed stages a few new stages and some branching. Instead, there is likely to be a week’s worth of work to return this mess to something that meets the client’s needs.

The story above is by no means an isolated incident – I was on another project last year where I had to redevelop large chunks of the implementation because of another Power Platform developer. I have heard many similar tales of woe.

So, if you are selecting team members for a Dynamics 365 project, and you need people with Power Platform or Power Automate skills, please ensure that they also have Power Apps skills. Otherwise, your project may end up in this woeful state – where easy configuration is replaced with complex code. This does somewhat make a mockery of the no-code lo-code paradigm.

If I can help you with your Microsoft Dynamics 365 project, or your CRM strategy, I would love to hear from you. I especially like helping you realise value from what you already have through empowerment, education and enlightenment around Microsoft Dynamics 365, Power Platform and CRM.

#CRMSuccess #CRMTraining #DynamicsTraining #D365Training #Dynamics365Success #MVP #MVPBuzz #D365Community #BizApps #SydneyBizAppsGroup #GillWalker #Opsis