A winner Power Platform environment architecture
As part of my role as Cloud Solution Architect at Microsoft, I often find myself answering a lot of questions from customers about the best practices to govern the Power Platform at an enterprise level, so I thought it’d be helpful to share some of the reccommendations I give them to a broader audience.
To me, and many members of the Power Platform community, a huge part of stablishing successful governance is having a clear environment architecture. This example shows one way of achieving it, and although there are many more approaches, this one has proven to be solid, easy to implement and comes at a very attractive price for the organizations I’ve worked with.
I will divide this post into a two-part series, one called ‘It all starts with the Default environment’ and another called ‘The power of Developer environments’. Stay tuned for part two!
It all starts with the Default environment
I’ve noticed a trend whenever I meet up with a customer who’s brand new at Power Platform governance, and it is that they usually want to take the most restrictive path possible. Generally, one of the first questions I hear is ‘How do I prevent users from publishing new apps or flows?’. And the answer’s always the same: You can’t prevent your users from publishing objects in the Default environment unless you block their access to the Power Platform entirely using an Azure Conditional Access policy. This counts for both end-users and creators.
As expected, this answer’s not generally the most satysfying one, as customers feel like the platform lacks governability capabilities, forcing them to either allow or restrict all kinds of access. But to me, it all comes down to understanding the purpose behind this environment.
Stablishing a level zero of governance
The reason why the Power Platform comes with a Default environment where all users in the tenant can create and share their own low-code creations is precisely to allow them to tap into the power of rapid app development and solve simple problems using easy-to-access tools. You need to collect approvals, have your team work with cloud-based forms instead of siloed Excel spreadsheets or simply send automated alerts every time a task is completed or a request is received by email? Then you should be able to use Power Apps and Power Automate in the same way you can use any other Office 365 tool to boost productivity.
That’s where the key to governing the Default environment is: You should allow your users to only work with approved Office 365 integrations when creating apps in this space. This means: Connecting to SharePoint lists and document libraries, Teams chats or the Outlook mailbox is okay, but sending HTTP calls to external APIs, connecting to Azure or on-premises databases and core systems is not.
And the way to achieve this is by stablishing a Data Loss Prevention (DLP) policy that applies to this environment and blocks all usage of connectors not listed as part of the Office 365 tools. This way, you are making sure that users are not creating connections to tools they already don’t have access to and that are not part of the core Office suite.
Nowadays, this policy contains 24 non-blockable connectors, which I’ve listed on the image below. (25 if you count the Microsoft Forms connector, which despite being blockable, I’ve seen is one of the most useful ones for business users looking to automate survey responses collection).
It’s worth mentioning that none of these connectors require a premium Power Platform license, so if your organization is still evaluating wether or not to purchase licensing, you can make sure your users won’t need them on this enviroment (with the exception of the Dataverse connector).
Communicate with your community of creators
Once you’ve created your policy, it’s fundamental for you to stablish a communication route for your users to understand what the ‘game rules’ are. That is, what are they allowed to create and using which connectors. It can either be a SharePoint site, a Viva Engage community, a newsletter, or my favorite, an automated email that gets sent everytime a maker creates an app or flow for the first time.
The good news is that the Starter Kit for the Center of Excellence already helps with that part of the governance and allows yo to customize an email to include:
- The DLP that applies to your Default environment
- Helpful documentation and self-study courses to begin with low-code creation
- Internal contacts who can help when someone has a question about the platform (it can be about licensing, technical issues, governance, or any other)
- Other important guidelines that apply in your organization
Ask about those new developments
This step might be seen by some as ‘micro-management’, but for a lot of IT administrators it is helpful, at least at first, to know what kinds of apps their users are creating, even if they’re limited to the usage of Office 365 connectors.
I’ve worked with some customers in expanding the Starter Kit for the CoE to create a simple flow that sends an automated message via Teams everytime a user creates either an app or a flow on the Default environment and requests a business justification for it, with the condition that, if no answer is received in a stablished time period, such development would get permanently deleted. (I might create a blog post in the future to explain how to create this flow in detail 🤔)
In this survey, we get the chance to ask questions about:
- The type of data that is handled by the app/flow
- The business purpose of the development
- The intended audience (number of users, departments, roles, etc.)
- The data sources (SharePoint lists or libraries URLs, OneDrive locations, etc.)
- The project’s roadmap
- Any other questions that might be helpful to fully understand the new app/flow
And this helps IT administrators to get ahead on possible upcoming requirements too, such as additional licensing, a more robust ALM infrastructure, assigning technical consultants to the project, etc.
Disclaimer: The Starter Kit for the CoE already comes with an automation and even an app to achieve this ‘auditing process’, but in my experience, this tool gets little adoption for two reasons: One, it is a premium-based solution, which means that all makers need a premium Power Apps license to access it and two, it does not allow for the customization of the questions in the survey.
Go all-in with the capabilities of Managed Environments
On 2022, Microsoft launched the Managed Environments for the Power Platform, which are a new capability that allows administrators to gain even more control over their environments.
One of the key features of this capability is to control the number of users and groups a Power App can be shared with. If you were to set this number to one, this would mean that users can create their apps on the Managed Environment, but can only share them with one other user; thus essentially limiting them to creating only assets for personal use.
This might be a bit of a radical approach, and IT administrators who decide to enforce it might experience some serious backlash from their creators community, so please, proceed with caution.
It’s also worth remembering that Managed Environments are a premium offering, which means that all apps and flows on this type of environment will instantly become premium as well. Don’t consider this possibility if your organization still does not have a widespread adoption of premium Power Platform licenses.
Wrapping up
The Default environment is the first point of access to the Power Platform. Stablishing a good set of guidelines to manage it is key to a successful governance strategy.
On the next part of this series we’ll answer the question: What if a maker wants to create a solution that does not fit under the parameters of Office 365 productivity that we’ve set up for the Default environment?
We’ll tap into the power of Developer environments, and review an example architecture that connects all pieces together.
Stay tuned, and please leave all the feedback you can! This is my first blog post ever, and I’m looking forward to share a lot more low-code knowledge with you all.
Less code, more Power! ⚡
