To establish the Power Platform environment for your kick-ass business applications, following the best practices and finely crafted strategy is very important. Top three steps, that go to the depth to checkmate the highly unruly environment are here in the list. Delivering benefits and keeping the confidence in citizen application platform, is highly critical and like with all great platforms and technologies, it is hard to achieve without putting the thoughts about strategy and architecture. While putting the strategy and working on the architecture, there are many aspects to look after but it always starts with establishing the environment on solid foundation.
Don’t use default environment
The default environment comes with every O365/M365 tenant. It is highly recommended not to be used for critical business applications. First of all, this (default) environment has fewer security controls as compared to other environments. The main use of this is for personal productivity tools like Office 365, SharePoint Online and Project for the web. All licensed users for Power Apps, Flow, Office 365 and Dynamics 365 Online, stand-alone licenses, free and trial licenses automatically gets the maker role in this environment. (Yes it is as scary as it sounds 😦 ) As an admin, the best would be to rename this (default) environment Personal Productivity to label it for once and for all.
Critical application deserves respect
Every business has mission-critical operations that deserve special attention. Identification of critical over important applications can help create segregated environments without costing a lot of resources. e.g. For Dynamics 365 applications, there should be a set of Dev/Test/prod environment of its own. If the compliance or security requirements need ring-fencing of the information, multiple isolated environments can be created for D365 apps too. But remember less is better when resources are limited, use this strategy for mission-critical and important apps, or on business units who need their own dedicated area.
Service accounts for production deployment
This may cause a few raised eyebrows. Yes, under European GDPR and other standards compliance, having a generic account with admin access is an exception. But the benefits of following this outweigh the possible issues(that can be managed and mitigated). Under this, we will use a service account that central IT manages to deploy to test and production environments. This will make all other users with no need for elevated rights and they can operate using end-user permissions and avoid unintended exposure. This can save on licensing too if premium connectors such as Outlook or SQL Server are required.