Power Platform tenant settings in PPAC are important for any administrator to know and understand. Microsoft often add or update these settings, so they’re critical to your ongoing governance.
In our experience, few are aware of this area in PPAC, let alone what settings are available for you to enable. In this article we’ll go over the key settings you need to consider for your Power Platform tenant.
First, to clarify: we mean tenant settings just for the Power Platform, not all of Microsoft 365.
That might sound obvious, but it’s a similar deal when talking about Data Loss Prevention. Admins enable wider DLP in their Microsoft 365 tenant, but they may not realise it doesn’t include the Power Platform. It’s the same for other settings too.
Power Platform tenant settings offer many useful features. This includes assigning who can create certain types of environments, pooling AI credits and more. There’s also a range of Copilot features making their way here too, so it’s important we keep pace with these aswell.
Where to find them
Did you check out our beginners guide to the Power Platform Admin Centre? If so, you may have noticed a short paragraph about Power Platform tenant settings.
To access it, log in to PPAC (insert link) and from the left-hand navigation, select Settings:
Caveats
At time of writing, it’s important to call out settings with this green icon next to them:
This means the tenant setting will only be active for Managed Environments. Any of your existing unmanaged environments will not be included.
Right, let’s get into our top recommendations. These aren’t in any particular order.
Environment assignments
In Power Platform tenant settings, there are currently three options for environment provisioning. They relate to developer, production, and trial environments:
Each setting is basically the same; it determines if anyone can create these environments or just specific admins. By ‘specific admins’, that means any account with the following role in Microsoft 365:
1- Global administrator.
2- Dynamics 365 administrator.
3- Power Platform administrator.
All three of these are set to Everyone by default. If you want control on who can create them, you’ll need to select the specific admins option. Don’t forget to save the changes too.
Recommendations
For Production and Trial environments, I’ll always recommend setting these to ‘Only specific admins’ because it’s easy to have environment sprawl otherwise. Creating environments involves knowing where data should reside, as well as security and other aspects. In the case of trials, it depends on your organisational circumstances. I’ve seen orgs leave this to everyone and it works well but their admin & monitoring maturity was high. For those less so, admins might be wiser to create these in the short term. Standard trials self-destruct after 30 days. So, there’s a risk of lost work if not moved.
Developer environments are great. They give makers a silo’d area to build and test Power Platform solutions. I think these are good for everyone to provision, but you must have the following in place first:
1) Robust Power Platform Data Loss Prevention.
You’ll need a tenant-wide DLP policy, with the scope set to ‘Exclude Certain Environments’. This means new developer environments will be automatically covered.
2) Process to request access to connectors.
To request access to a blocked connector, makers will need a simple process to follow. A maker with their own developer environment may want to test a specific connector, that would have huge business value.
3) Good monitoring in place.
Makers could create a developer environment but never use it. Consider removing unused developer environments after x period of time.
Analytics
A key setting I encourage to have turned on. Tenant-wide analytics collects lots of data and stores it in the Default environment. This data lets you see the reports under the Analytics tab in PPAC.
Enabling the setting is simple; find the Analytics option and toggle to Enable. It can take up to 48 hours for data to start flowing through.
You can read more about this setting here.
Capacity and licensing
There’s a couple of settings relating to capacity & licensing. Each of these settings gives you the same choices as to who can see the data or allocate what’s required. The settings are:
1- Tenant capacity summary view.
2- Tenant licensing summary view.
3- Add-on capacity assignments.
For the tenant-based ones (1 & 2), you can restrict solely to Tenant Admins or open up to Environment Admins too.
The Add-on capacity assignments setting is similar, giving you the option for specific admins (which translates to Global Admins or D365 Service Admins), or any Environment Admin.
For both, the Environment Admins option is all or nothing; you’re either giving the ability to all environments or disabling altogether. There’s currently no in-between option, where you can allow for some environments but not others.
Recommendations
It would be great to have the ability to turn on for specific Environment(s) and/or Admins. This would allow delegation to others and remove bottlenecks. Until then, I suggest keeping these settings to Tenant or Specific Admins.
Where this sometimes causes a bit of an annoyance is if the environment has per-app license capacity. PPAC is currently the only place where you can gain analytics on these, so would be something for which Environment Admins could self-serve.
Auto-claim policies
This is a neat feature in Microsoft 365, because it removes the need to assign licenses manually. Let an auto-claim policy do that for you instead.
If a user tries to open a Power App with Premium features but lacks a license, the auto-claim policy will give them one. Pretty cool, right?
You create and manage auto-claim policies in the Microsoft 365 Admin Centre, under Billing > Licenses > Auto-claim policy. You’ll need to be a Global Admin of your M365 tenant to create and manage auto-claim policies. You’ll therefore need to work with those in your business who have that level of permission if it’s not you.
How can I determine who an auto-claim policy has assigned a license to? Well, in the same area in the M365 Admin Centre, you can select a policy to access the View report option. This will present all users who’ve been assigned a license and you can download the information too.
This is especially important to understand because of the dedicated Auto-claim policies setting in PPAC. Here, you can choose where to trigger an auto-claim policy for the Power Platform. You can choose an auto-claim policy for every environment in your tenant, or opt for just for managed environments. By default, no option is selected:
If you already have at least a single Managed Environment, the M365 Admin Centre will automatically create an auto-claim policy for you. This is the Auto-Created Policy for Power Apps policy shown in the image above, however you can edit or delete this policy if you want to. You can read more about auto-claim policies for Power Apps licensing here.
Where these might cause more work is if you already have group-based licensing in place. If a user gets a license via an auto-claim policy, then gets added to a group with group-based licensing, you’ll have to unassign their auto-claimed license. You can unassign with PowerShell or do so manually.
I must admit, I’ve not used auto-claim policies much yet. I’d therefore be keen to hear from any Admins who have. Firstly, what are the pros and cons? Secondly, are auto-claim policies the way forward or do they bring different admin challenges? We’re keen to find out.
AI Builder credits
In the Power Platform, you can use pre-built AI models or custom-build your own, to subsequently use in your apps & flows. When these models are run, they consume AI Builder credits.
How do you get AI credits to consume? You can buy these as separate add-ons, alternatively you’ll get credits for each Premium or Per App license you buy. You can find out more information about this here.
In PPAC, we can go to Resources > Capacity and see how AI Builder Credits:
Selecting Manage opens up the Manage add-ons side pane. Here, we can select an environment and configure how many of our credits we want to associate with it. We can assign credits across different environments. 
Why is all that important? Well, notice the text in the image above -”Unassigned credits can be used on any environment”. Hopping back into PPAC, there’s a dedicated setting to help determine the behaviour of how AI credits are pooled and used:
Environments without AI Builder credits can use unassigned ones from across the tenant. That’s going to be pretty good if there’s some kind of random spike in activity and you don’t want to lose business continuity. Enabling this setting could therefore be useful.
However, for budgeting and forecasting, you may only want credits to gobbled up by the aligned environments. Keeping this setting disabled is going to be a better fit here. Subsequently, you’ll need to purchase additional credits if you’re environment needs more or reassign from another environment’s capacity.
Copilot related
It’s certainly no surprise there’s now several Power Platform tenant settings relating to Copilot. There’s currently 5 you can enable:
The top one is a bit of a red herring, I believe it only turns off Copilot for makers. It won’t disable the Copilot control for canvas or model-driven apps. Even if you do turn this one off, it’ll turn itself back on again anyway!
We were all set to explain these settings a bit more but as luck would have it, Carsten Groth recently published this article. Go and check it out for more info. Carsten posts really good content anyway, so if you’re not following him then now is a good time to do so.
Managed Environments related
At present there’s a couple of settings dedicated to Managed Environments. Following their introduction in 2023, I’d expect Managed Environments to grow in 2024, so can eventually expect related settings to grow too. If you’re about to or have already embraced Managed Environments, these settings are important to know about.
At time of writing, Environment routing is still in preview so use with caution. This setting allows admins to direct new visitors to make.powerapps.com to their own developer environments. This means they’re kept away from the Default environment as their, well, default place to build things. These developer environments are Managed Environments. Their sharing settings are pre-configured, among other things.
This is a cool feature, though I will stress the importance of a solid tenant-wide DLP policy being in place before you enable this. You can find out more about this setting here.
Weekly digest is handy for keeping an eye on both popular and unused assets in any Managed Environments across your Power Platform estate. As per the text in the setting, richer analytics are available if the Analytics setting is active.
Customer Lockbox is a cool feature. If Microsoft need access to your tenant to help resolve an issue, most of the time they won’t need to see your data. So, we must be mindful of any third party, even Microsoft, accessing sensitive information. With Customer Lockbox, you can set policies so any external party needs approval to access data. Any such requests will await your approval in the Policies > Customer Lockbox area of PPAC.
When the Desktop flow actions in DLP setting is on, you’ll see additional connectors you can allow or block in a DLP policy. They’ll appear as the light blue icon ones when searching for Desktop:
With the setting enabled, you’ll see these option in ALL current and future policies. However, any alignments to Business, Non-business or Blocked only come into effect when applied to any Managed Environments.
Recommendations
When this was first announced I was apprehensive with the idea of extra governance being behind a paywall of sorts. However, to use Power Automate Desktop you need Premium licensing anyway, so it could be sensible to make dedicated RPA environments for RPA solutions in your organisation. Following that, you can then convert them to Managed Environments. Then, give those environments a dedicated DLP policy so you can allow or block the extra connectors.
Self service billing
“If you are a Global Admin, Global Reader or a billing admin, you should check for self-service purchases as well (and if you don’t have any of those roles, get in contact with someone who has).
There is a whole list of self-service purchase possibilities. That means, user can buy a license on their own, with their own credit card and use it on your tenant. Do you like shadow IT, because that’s how you get shadow IT 😁
First, how to check if there are any self-service purchased licenses in your tenant: Navigate to the M365 Admin Center and select Billing >> Your Products and on the very right hand side you will find a filter (there should be 5 aspects already be pre-selected. Open that filter and at the very bottom you can select “Self-Service”. 
Luckily there’s also a way to switch off self-service for every product in your tenant. We will need PowerShell for that, but don’t you worry, I’ll be your guide 🧙♂️.
Ways to disable
At first we need to download and install that MSCommerce module from the PowerShell gallery.
Then we need to open a CLI of our choice (PowerShell, PowerShell ISE or the Command Prompt) and use the cmdlet (that’s how we call commands in CLI) Connect-MSCommerce to connect to the module. We need to provide the credentials of our Admin account to get access.
Then we use the cmdlet Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase to show us all products that allow self-service purchases and we can also see, if users can buy licenses on their own (the value is set to enabled then) or not (the value is set to disabled then). 
Here we can see that self service purchases are enabled for all of these products.
We have two options now: First, we can disable every product on its own with this cmdlet:
Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0H9MP -Value "Disabled"
The purple part is the PolicyID and in this example I choose the ID for PowerBI Pro. If you want to disable another product, you need to put the respective ID in that cmdlet.
The other option we have is to disable all products at once with this cmdlet:
$Products = Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase
foreach ($Product in $Products){
Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId $Product.ProductID -Enabled $false }
When you’ve done this I would like to encourage you to add the disabled products in your Power Platform Governance Documentation (you should really have one, if not, keep following our series, there’s a blog about that coming soon 😉)”
Thanks for reading. If you liked this article and want more helpful insights into life as a Power Platform Administrator, don’t forget to follow us on socials 😊.
All articles in this focused series will be curated here. Feel free to add it your favourites for your one-stop-shop for all your Power Platform Admin needs. Is there a topic we’ve not covered? Reach out to us and let us know!
Michael’s Blog, Twitter & LinkedIn.
Craig’s Twitter & LinkedIn.
I’m truly delighted to have subscribed to your series. Despite spending considerable time in the PPAC and regularly uncovering new features, your post has enlightened me on certain settings that would have taken me a while to find, especially considering my recent lack of Global Admin role.
Thanks for another insightful article. There is always something to learn even in areas that one thinks they have some considerable experience. Great stuff.