Tag: administrators

Environment Grouping

One of the main ‘complaints’ that Power Platform administrators have is around how policies are applied to environments. Within Azure, it’s possible to set up security policies and apply them in bulk, or group together components under a single set of policies. However when it comes to Power Platform, this has not been possible – each environment has needed to be configured on its own.

I’m not talking here about DLP policies, as these are set up and then relevant environments selected/deselected as needed. I’m talking about things like setting Canvas App sharing limits, welcoming new makers, and other items.

Well, Microsoft has now made this possible to do – though the current first iteration (now in Public Preview) only has a few options within it, I’m quite certain that many more items will be coming down the line to fall under the new Environment Grouping feature.

At the moment, there are 6 options available for Power Platform administrators to be able to set and configure. Note that you do need to have the M365 security roles for either Global Tenant Administrator or Power Platform Administrator to be able to access and carry this out.

To be clear, Environment Grouping is a feature of Managed Environments. I’m not going to go into the debate about whether you should or shouldn’t adopt Managed Environments (at least not here – I may be speaking about it publicly later on this year), but you do need to have these in order to use this functionality. More specifically, you will ONLY be able to add environments that are set as ‘Managed’ to Environment Groups (though they don’t have to have Dataverse in play):

So, what exactly is the purpose of Environment Grouping? Well, it’s to minimise the amount of time that Power Platform administrators need to spend in setting up & applying policies.

Think of the users within your organsiation. You’re going to have different personas, such as developers, testers, end users, etc.

You’re also likely (especially in larger organisation) to have different business units & functions requiring different items. For example, you may lock down access to social media, but Marketing and Recruitment may indeed need access to social media to be able to carry out their jobs.

With these personas in mind, you can then start to look into building out different rule groupings, which will apply to all environments that are included under the Environment Group. It’s somewhat similar to the way in which DLP policies work – you create a DLP policy, and then everything that comes under the DLP policy gets the DLP policy setting.

There are many ways to manage pockets of environments within your tenant using environment groups. For example, global organisations can create an environment group for all environments in each geographic region to ensure compliance with legal and regulatory requirements. You can also organise environment groups by department or other criteria.

One of the other features around Environment Groups is the ability to use Environment Routing. I’ve talked about this previously when the feature was first released (Developer Environment Routing!) – Environment Groups now takes this to the next level, by being able to automatically set the Environment Group that new developer environments will fall under (so therefore policies will be automatically applied). Important to note here that all developer environments created through this WILL be set as ‘Managed’.

More information on the new capabilities can of course be found on Microsoft Learn, at https://learn.microsoft.com/en-us/power-platform/admin/environment-groups.

I think that this is a great new feature to have in place for Power Platform administrators, and look forward to seeing new functionality rolled out within this to enable organisations in a better way. Being able to cut down on administration/governance time, whilst being able to be more effective is, in my view, a win-win for ALL of us, and I can’t wait to see how it will develop over time.

So, my question to you is how would YOU look to use such functionality? What features might you like to appear within Environment Grouping to enable you and your organisation? Drop a comment below – I’d love to hear!

Developer Environment Deletion!

Strong title for a blog post, right? Well, I did want to catch your attention! So what exactly are we talking about here?

For the last few years, it’s been possible for users to sign up for a ‘Developer’ plan, which gives them a full capability Power Platform environment for free (though with some limitations to them). This used to be be called the ‘Community’ plan, and is an amazing resource for everyone, whether they’re a professional or citizen developer, to have their own personal ‘sandpit’ to play in, and try things out.

Let’s wind back a few months in time now – earlier this year, Microsoft announced that users would be able to create THREE of these Developer environments, rather than having just a single one! This was mind blowing news, and something that has been extremely welcomed. If you’re wanting to see more on the announcement, Phil Topness has a great video on it at Dataverse Environments For Everyone – New Developer Plan – Power CAT Live – YouTube.

Incidentally, I’m curious as to how much storage space Microsoft has in the background to handle these. After all, each environment takes up a minimum of 1GB of space (& can grow to 2 GB). That means that each user could have 6GB of storage being used….which when multiplied, gives a VERY large number!

Microsoft has now announced that these developer environments, however, need to be utilisied. Ie if they’ve been created, but aren’t being used, Microsoft is going to delete them! Now, from a certain perspective, this is actually quite good – after all, there are all of the storage considerations for environments that have been created, but not being used. However from a different perspective, this could be a problem. What about if you’re doing something occasionally in an environment, but not too often? What about if you decide to go on a ‘Round the World’ cruise for several months?

So let’s look at the definition for this. Microsoft states that an environment is considered to be inactive when it hasn’t been used for 90 days. At that point in time, it is disabled, and the administrator or environment owner is notified. If there is no action taken within the next 30 days, then the developer environment is automatically deleted.

Now, how does Microsoft define ‘Activity’? It goes something like this:

  • User activity: Launch an app, execute a flow (whether automatic or not), chat with a Power Virtual Agents bot
  • Maker activity: Create, read, update, or delete an app, flow (desktop and cloud flows), Power Virtual Agents bot, custom connector
  • Admin activity: Environment operations such as copy, delete, back up, recover, reset

The above is all user driven – ie a user needs to interact with something within the environment. However, it’s also important to note how automation is viewed:

  • Activity includes automated behaviors such as scheduled flow runs. For example, if there’s no user, maker, or admin activity in an environment, but it contains a cloud flow that runs daily, then the environment is considered active.

It’s also important to note that at this point in time, the above only applies to Developer environments. Other types of environment (Production, Sandbox etc) don’t have any auto-deletion policies called out for them – well, at least not yet (if something does pop up around these, I’ll definitely look to talk about them too!).

So to answer our question above about what happens with a (developer) environment that is only being used infrequently – the way to stop it being auto-deleted is to put some automation in place. This doesn’t need to be lightweight – it can be something simple & easy, just to ensure that the environment registers activity happening within it.

In my view, it would be nice to have some granularity & control over this as well – allowing organisations to set their own deletion policies. We have this in place for things like audit log retention – it would be nice to have have it in here too.

Updates to the Power Platform Admin Center

There’s a saying amongst seasoned IT professionals who deal with Microsoft software. It goes something like this – ‘Why make do with one admin centre, when you could just have MULTIPLE admin centres to carry out functions!’.

It’s a bit of a tongue-in-check response to the numerous different admin centres that Microsoft technology seems to have. Now, I/we totally understand that over time, different (standalone) products have come together to co-exist, but their administration centres still differ.

Over time, Microsoft has been applying efforts to make them work better together, but it can still sometimes be quite frustrating not to know exactly where to go to in order to carry out specific function/s, or not to be able to see capabilities holistically overall in a single place.

So for example, we have:

  • Microsoft 365 Admin Centre
  • Power BI Admin Centre
  • Power Platform Admin Centre (which, for Dynamics 365 deployments, still leads users to the Classic Advanced Settings for some of the functionality…)
  • etc….

Now when it comes to Power Platform related items, admins would usually go to the Power Platform Admin Centre (which though it has a URL of admin.powerplatform.com, this auto-resolves to admin.powerplatform.microsoft.com – I have no idea why this is, given that no other admin centre seems to have this structure in place….another mystery…)

From here, we’d be presented with a list of environments, similar to the screenshot below:

The menu on the left hand side gave us a few of the different admin centres that we’re able to switch to. Alternatively, we could expand the overall menu to show us more capabilities, including other apps that we may wish to access:

So this is what we’ve been used to for the last few years. Essentially, information in different areas, and we’d need to go to each admin centre to find out what’s happening. So for example, if a Power Platform Admin user wanted to see any health advisories, they’d need to go to the Microsoft 365 Admin Centre to view the Service Health area there.

Not anymore! As part of the focus on unifying information across admin centres, Microsoft has now updated the functionality for this!

Now, with the new functionality, there’s a Home screen. On this, information is able to be presented to users, as well as applying one of several themes to the interface, such as a rainbow:

Now, in terms of information available to users, these are presented as ‘cards’. Within each card, information is shown, based on the card type:

At the moment, there are three cards to choose from:

Service Health

This section outlines any service health issues, such as outages or advisory information that users should be aware of. Clicking through it will bring users to the Service Health section of the Microsoft 365 Admin Centre:

From here, users can choose to switch across to other categories, such as Incidents, History & Reported Issues.

It’s (at least) one less click from the previous method, and I’m quite liking this. In my mind, it’s about making the information as accessible as possible (leaving aside that I think that Power Platform specific alerts should actually show within the Power Platform Admin Centre…)

Message Center

The second section is the Message Center. Here we’re able to see specific messages (yes, I know I have a LOT of messages sitting here!), and clicking on them will bring up the corresponding information directly within the same interface (which again, I’m really liking). So for example:

Nicely for messages, we also have options to filter the types of services that we want to see here. This, in my mind, is quite important, as we wouldn’t want Power Platform admins to be overwhelmed by messages that have absolutely no (usual) interest for them:

We also have the ability to specify which email notifications we want to be receiving. Again, we may be interested in some non-Power Platform notifications, but not want to see them directly within the Power Platform Admin Centre. Instead, we can specify to receive these via email – another nice touch!

Documentation

Finally, we have linked out to various Power Platform (& Dynamics 365) related resources on the Microsoft website. These are all static (ie they’re provided by Microsoft), but hopefully in the future admins will have the capability to add custom links to other resources as well.

What is nice about the documentation section though is that it’s got linked to the various Community forums. Microsoft has recently started to promote these within the products, and they can be a very helpful resource at times to be able to use!

There are also links to the Microsoft Centre of Excellence toolkit, which is a great resource that organisations should look to implement.

All in all, I think that this is a VERY good start to things. I’m hopeful that with Microsoft implementing this ‘home screen’ functionality with the ability to add cards to it, there will be additional cards that are released, bringing more information & functionality into the interface. I’m also hopeful that Microsoft will allow admins to add custom functionality here as well.

It’s a good first step – now let’s wait to see how this functionality iterates over time, and hopefully enables admin users in better ways!