Power Platform | A closer look at the Developer Plan

As you might have heard the previous Power Apps Community plan has evolved and we´re now talking about a Power Apps Developer Plan. So I was approached the other day in terms of questions upcoming like:

Do we sign-up for Developer plans for all our developers now and avoid us paying for premium licensing?

Anonymous CIO

And you know me, I love to deep dive into licensing discussions, so why not give the new Developer plan a chance, drill into the details and facts we currently know. Plus share some thoughts around the governance and licensing model around it. Before we get started, I should add that the Developer plan is an extension of the capabilities that previously were offered through a Community plan. It is worth studying the details inside the official documentation, as things may change over the next couple of months.

First things first, even without a license being assigned, any user would be able to enter the Power Apps Maker experience by simply opening https://powerapps.microsoft.com/ – sign-in with their work account and they should be able to see above UI. Didn´t know that?

Above visual shows you that my test user Carl Citizen isn´t assigned any license, except being part of AAD and being able to sign-in. Being a Global Admin or Power Platform Admin, if you haven´t controlled access to above URL, your user would simply answer a one-time question around their location and things would be configured for them. As you can see from the first visual, the environment that will be used for this experience is the default environment of your organization – which typically follows the naming pattern [Your Orgname] (default).

That might already answer above question around licensing. Would I need a Developer plan license to create something? No. You can clearly create or make without a license. Though, at run-time you would need to have licenses to host your application, flow, chatbot or portal in your production environment. With that, let´s see what happens, if Carl Citizen follows the instructions from the landing page and signs up for a new Developer plan.

Carl will be presented above page and needs to provide his country information and accepting the Power Apps terms of use and Microsoft privacy statement. Again, assuming that the Global- or Power Platform Admin in your company hasn´t implemented any other Governance model around this. Or in other words, we´re still talking about the out-of-box behaviour. So what´s next?

After a short preparation time, Carl will be forwarded directly into his new Developer Plan environment – this can be easily identified as the naming pattern would be „firstname lastname +’s Environment„. See above visual and check out the environment switcher to the right in the header (purple). Now check out the gray notification telling that this is a developer environment and not meant for production use. So that´s it. Carl created a new developer environment and signed up for a Developer plan. Pretty straight forward, right? But wait…

What happened behind the scenes? The Global Admin or License department will find a newly added licenses called Microsoft Power Automate Free valid for 10k (if not previously already existing). Everyone who signed up for a Developer plan will be assigned such license + your Global Admin. That´s why in my test case, 3 of the licenses have been assigned to users already.

Beside that, Carl now also is able to enter the Power Platform Admin Center. He will be able to monitor his personal development environment. Additionally, he will be able to create new environments as it is documented – Create more environments to exercise application lifecycle management (coming soon). While testing this function, I was presented an error message that the community plan doesn´t allow for adding additional environments. Let´s review this part in a follow-up.

Now, let´s check the Global- or Power Platform Admin side as it currently might feel a little uncomfortable by someone adding an environment to their Tenant.

IT departments following the principle of least privileges, might have set the above setting. In other words, they´ve restricted environment creation to be valid only for specific roles. So the question resulting is:

Why was Carl able to create a Developer environment?

Power Platform Admin centrally managing Power Platform

The answer can be found, in the type of environment that got created.

As you can see from above visual, both Renee and Carl in my test case created themselves Developer environments. The Power Platform settings indicate that you only restricted environment creation for production and sandbox environments + trial environments. Therefore, both of them were able to create those types of environments. You may ask where´s the setting to control those Developer plan environments? As I said, be aware of changes and upcoming features to this new Developer plan.

One of the next main concerns a Power Platform Admin may raise might be around DLP policies. So let´s take a look.

In my test case, the Power Platform Admin created a „General rule of thumb“ policy that spans across all environments, including those newly created, but excluding one specific environment. So from this point, you should be safe. But what about the fact you´re going to create a new DLP policy?

Again, you can calm down, as you should have been added to each of those environments automatically from a Global Admin perspective. So you are able to select those environments and you would be able to setup a Developer environment specific DLP policy.

I should note though – being a Power Platform Admin, you may not have been added automatically to those environments and therefore you´re not able to select those. The feature matrix talks about this specific behaviour. The fix here would be to get in co-ownership of those environments. So you may make a note for your Governance playbook to get this task covered.

Another note: Since both Renee and Carl in my case created Developer environments and own them, they are also allowed to setup individual DLP policies that work for owned or co-owned environments. Make a note in your Governance playbook to ensure those DLP policies being created by Developers later on might need sanity checks, especially if the Developer left the company.

Wrapping things up my current „assessment“ is as follows:

• Do you want your users to individually setup Developer environments that over the time may become „troublemakers“ in terms of Governance?
• Do you wish those Developers to add coworkers individually to those environments as Environment Makers and -admins?
• Do you want them to create DLP policies additionally to your centrally provided DLP policy setup that remain valid for those environments they own or co-own?

Maybe a better idea – at least for an enterprise organization – would be to follow a different approach and setup dedicated, shared developer and test environment(s) instead. At least makes it easier,

• from the amount of environments existing in a Tenant
• from who is given Developer access to those environments
• from who is under control of DLP policies around those environments in terms of management and adjustments
• from training Developers on following ALM principles

Keep in mind the license creation and auto assignment I introduced at the beginning. You may prefer a clean license structure in your tenant due to internal cost center and invoicing processes. Additionally, think about using the Center of Excellence Starter Kit if not already in place, as it will offer you monitoring capabilities to identify those new Developer plan environments. And finally, let´s not forget – this is an extension of previous Community plan. Changes and improvements expected. Until then, …