When organizations begin using Microsoft Power Platform, one of the most important steps is establishing proper governance and administration from the start. In this video, Brian Knight from Pragmatic Works walks through five key actions administrators should take first when setting up or inheriting a Power Platform environment. His guidance is designed to help organizations avoid common mistakes, control resources, improve security, and create a scalable structure for future development.
Brian explains that while there are many administrative tasks worth considering, these five are among the most urgent and impactful. He begins in the Power Platform Admin Center, which can be accessed through make.powerapps.com or make.powerautomate.com. From there, he shows how administrators can apply settings that support stronger governance across the organization.
The first and perhaps most critical step is controlling who can create environments. Brian notes that by default, anyone in an organization may be able to create a new environment. This can lead to unnecessary storage use, poor governance, and misuse of purchased resources such as add-ons and premium capabilities.
He recommends limiting the creation of production and sandbox environments to specific admin roles, such as:
Brian explains that trial and developer environments are generally safer to leave open because they do not consume the same organizational storage in Dataverse. Restricting production environment creation helps prevent users from setting up unmanaged environments that consume resources and create governance challenges.
Next, Brian emphasizes the importance of clearly naming the default environment. Many organizations leave the default name unchanged, which can confuse users and encourage them to build important business applications in the wrong place.
He recommends renaming the default environment to something more descriptive, such as Personal Productivity. This makes it clear that the environment is intended for smaller, personal, or team-level apps rather than enterprise-grade business solutions.
Brian explains that this naming strategy helps communicate expectations. It encourages teams to reserve Dev, QA, and Production environments for formal application lifecycle management while keeping the default environment focused on lightweight, less critical solutions.
Another major priority Brian highlights is setting up Data Loss Prevention, also known as DLP, policies. DLP policies help organizations define which connectors users can access and how data can move between services.
Brian recommends creating a restrictive DLP policy that applies broadly across the tenant, while excluding approved Dev, QA, and Production environments. This creates boundaries for users in less controlled environments and reduces the risk of inappropriate data movement or unsupported app architectures.
His suggested approach includes:
This approach gives users enough flexibility for personal productivity while protecting enterprise environments with stronger administrative oversight.
Brian’s fourth recommendation is to assign security groups to environments whenever possible. Without security groups, too many users may be visible within an environment, making administration harder and increasing the chance of unauthorized access.
By associating an environment with a security group, administrators can control who is allowed into that environment more effectively. Brian explains that this is especially useful for environments other than the default one. A well-managed security group structure makes it easier to onboard the right users, reduce clutter, and simplify environment administration.
He also notes that when creating a new environment, administrators should ideally define the security group from the beginning. That way, access is controlled immediately rather than cleaned up later.
The fifth item Brian covers is theming. While this may seem less urgent than governance or security, it still plays an important role in creating a professional and recognizable experience for users.
Within Power Apps advanced settings, administrators can customize themes by adjusting colors, icons, and logos. Brian demonstrates how to clone an existing theme, rename it, and update the visual elements to better align with company branding.
Custom theming offers several benefits:
Even though theming is often considered a finishing touch, Brian shows that it can still be an important part of environment setup.
Before ending the video, Brian shares a few bonus recommendations. He encourages users to build applications within Solutions rather than creating them directly in an environment. This supports portability, better lifecycle management, and easier deployment between environments.
He also suggests reviewing product and feature settings to enable useful capabilities such as mapping, co-authoring, collaboration, and other preview features when appropriate.
Brian Knight’s walkthrough provides a practical starting point for anyone responsible for governing a Power Platform environment. By controlling environment creation, renaming the default environment, applying DLP policies, using security groups, and setting up themes, administrators can create a cleaner, safer, and more scalable foundation for future development.
For organizations using Power Platform seriously, these steps are not just helpful, they are essential. Pragmatic Works continues to provide expert-led training to help teams configure environments correctly and build with confidence.
Don't forget to check out the Pragmatic Works' on-demand learning platform for more insightful content and training sessions on Power Platform and other Microsoft applications. Be sure to subscribe to the Pragmatic Works YouTube channel to stay up-to-date on the latest tips and tricks.