Let’s start this thing with an expansion of the introduction on the home page. It has become extremely popular in the last year, so there’s some key points to consider what Power Platform and Dynamics can do and where it’s going. Firstly, the very basics, what are the core tools and are you aware of them all existing?

• Power Apps – Canvas
• Power Apps – Model Driven
• Power Automate
• Power BI
• Power Pages (formerly Apps Portals)
• Power Virtual Agents
• Dynamics 365
• Dataverse

Trends

There’s always been trends in I.T. from the useful to the fads, Power Platform is no different. The tools were created 6 years ago, with the longest experience around 4 years, but usually 1-2 and primarily canvas Power apps. This is fine, but now we’re going through the explosion of companies jumping on it (presumably as the new thing to make quick money from), there seems to be a dangerous lack of consideration of the platform being more than Power Apps, as well as other topics below.

This is the primary focus of my blog, as I want to spread useful knowledge I’ve picked up in my own job and from colleagues. I love the tools and think they are incredibly powerful, with a lot of potential, however it is incredibly easy to do things badly with no focus on ALM and governance

Not Only Low Code/Citizen Developers

Although it started as a toolset for “Citizen Developers”, there are more and more aspects that need to be considered and technical options available, which now show it is anything but only that. The sheer number of options available (listed above), provide many different approaches to providing what users need, with some being potential replacements to traditional coding methods such as HTML, CSS, JS, .net, Java etc and some complementary. There is no one size fits all in software development and this couldn’t be truer of Power Platform – embrace what they do, but be cautious.

2 key aspects (which you’ll see repeated quite often) that are now incredibly important for pro developers are ALM and governance. ALM (Application Lifecycle Management) should consider the following:

How and where do you make your changes?
How and where do you release them?
Is this manual or automated?
Who can do it?

It is best practice that you should always use solutions. Solutions are effectively groups of customisations, be it apps, cloud flows, JavaScript files, connection references, variables, many things and come in 2 types – unmanaged and managed. You should always make your changes in an unmanaged solution in a dev environment, then release them as managed into QA (any number that suits your org) and live. Never make changes in any environment other than dev, as you will cause layering where next time you import, the updates will never trump the direct change.

Manual exporting and importing is a useful method of releasing, however this comes with certain risks:

Values from variables have to be removed prior to export (very time consuming).
Owners of customisations become the importing account (risky if not a service account).
System Customiser is required for the account performing this action (risk if on a personal account, as this will give access to nearly every part of that environment).
General human error (it’s a manual process).

Automation is possible either via Power Platform pipelines, or Azure DevOps. Pipelines are excellent, but you cannot run tests or external steps, have limited visibility, owners and permissions are as above (the import still happens as the running user). They show a lot of potential, but for enterprise systems, I would not use these in their current early stages.

Azure DevOps is far more robust, as you have full control, can connect as an Azure App Registration, have any type of approvals or gates, backup the zips, link to work items. You cannot operate in the exact same way as coding ALM, such as Pull Requests, as there’s no code to review, but there are ways to mimic this process in alternate ways effectively. This would be my chosen method of releasing to reduce risk and increase efficiency.

Governance

Governance is the definition and management of the operational side of the platform. The most common and critical areas are licensing, environments, security. Without well defined usages of each of these and control of that, the entire platform and applications/processes within it would become unsupportable in months.

Licensing is important as it is so complex. For example – there are 3 direct ways to build Power Apps and Power Automate (free with A/E3 without non-premium connections, Per App/Flow and Per User), with Power Pages and Virtual Agents being usage based and BI having desktop and service. I wont go into the details here, but a useful starting point is keep it basic – use what you get out of the box and don’t dive into wanting hundreds of Dynamics or Power App licences (again – canvas apps are not the entirety of the platform), as that when the common question will soon appear of it being unaffordable. Build, research and iterate your requirements and solutions, then ask on communities like Reddit and Discord for advice.

Environments are fundamental to professional development in the platform. You will always have a default environment and as per Microsoft’s own best practice (see training below), this should be for non-business critical work only. This is the one and only place where the “citizen developer” idea should be allowed and they should not be able to do anything more than standard flows, apps etc. When you start to build a proper ALM process, you should at least have dev, test and live, but I would argue 4 – dev, QA (internal test team), UAT (wider organisation testing) and live. Each environment should have well defined and limited access, such as own accounts in dev, only test accounts in QA and no engineering access to live. This is where security comes in, where those different accounts can use a mix of out of the box roles and custom.

All of the above should be managed by an infrastructure team separate to engineering, but open to suggestions from anyone, as any good agile workplace should. Infra and engineering will act as 2 sides of the same coin to maintaining a safe and productive system, with one having no more influence than the other.

Training

Questions that comes up more regularly than they should are do I need experience to pass an exam? What jobs can I get after passing an exam? Can I get a pay rise after…I think you can see the pattern. Exams have virtually no impact on jobs – forget about them. If you want to do a certification, it should be for you and you only to measure your experience, personal fulfilment, whatever you want from it. The key aspect is the Microsoft Learn material – it is incredibly well structured, covers many topics and a perfect complement to practicing on the job.

That is the key point – practice. Experience wont grow and exams wont be passed by just doing the material, knowing how it relates to the real world is very different and also fulfilling. This is like any IT role – software developer using code, tester, networks and it shouldn’t be expected to walk into senior roles after a year, this is no different in Power Platform.

Key courses to do are PL-900, 100 and 200 in that order. This will give you a great general knowledge to then apply. You can branch out into specifics such as Azure by doing 400, Power BI or chatbots with 300 and 500, all culminating in an overarching view of the entire ecosystem which you will need to be a tech lead, in PL-600. These are difficult – just like a degree is to learn C# or Java, so take from them what you want and need. Visit this page on Reddit which will give a wider view of the various options.