Managing Environments
In my previous posts about establishing a Center of Excellence, I briefly mentioned Power Platform environments. In this part of my series, I am going to deep dive into managing environments.
Environment usage planning
Rolling out PowerApps or Power Automate in a large organization requires much initial planning, and providing environments is definitely an important topic. Before I continue, let's have a look at some definitions first. A Power Platform environment is a container that is used to host artifacts. Those artifacts can be a Dataverse database, a PowerApps app, or a Power Automate Flow. Besides, Power Platform environments are also used to "enforce" corporate Governance as DLP policies can be defined and connectors can be allowed or blocked. In other words: a Power Platform environment is somehow similar to a SharePoint site as both are also used to create an internal structure, both are used to host artifacts and data, and both use groups of users to manage access permissions. Organizations need to plan how their corporate entities use SharePoint sites - and the same is true for Power Platform environments.
Usage Strategies
Let's continue to utilize the SharePoint site example a little bit longer. In most organizations, each corporate entity gets a SharePoint site to promote their work and publish information. As an example: HR gets a site to publish employee-related information, Marketing gets a site to publish marketing materials, and the Executive Board gets a site to publish business plans. There are other strategies out there, but let's stay with this classic approach for now. With Power Platform environments, it can be similar. Many organizations provide each corporate entity with a Power Platform environment. HR can create their new Vacation Request app in their environment, and Marketing can create their new Marketing Materials Request Form in their environment. Having each corporate entity use a separate environment makes sense because it ensures that entities can manage their artifacts on their own. This is where the similarity ends. Usually, corporate entities do not need to request a SharePoint site. However, many organizations have implemented at least a fundamental request process for Power Platform environments to utilize resources based on actual demand.
Environments and Data Repositories
At the beginning of this article, I mentioned data repositories. A Power Platform environment can also be used as a data repository, which makes planning a lot more complicated. A Power Platform environment can also host a Dataverse database (formerly known as Common Data Service). As soon as a Dataverse database is hosted in an environment, things become much more complicated. Even though a Dataverse database is often referred to as a SQL database in the cloud, this is not entirely true. Data is stored in tables very similar to a SQL database, but managing access permissions is much more complicated as Dataverse provides a much more sophisticated way of providing access permissions. This is where many corporate entities get frustrated. They want to use Dataverse to store their data because it appears to be very convenient to host data, apps, and workflows in a single container (the Power Platform environment), but once they noticed that managing permissions is much more complicated (especially if permissions need to follow corporate security guidelines), that's when the frustration begins.
Environments and Corporate Policies
Using Power Platform environments needs to follow corporate guidelines regarding Governance and Security - that's again similar to SharePoint sites. Those guidelines affect how permissions are handled, how apps and flows are created and published, which connectors can be used, and what data can be stored in Dataverse databases.
Environment-related Governance and Security guidelines must be in place before providing corporate entities with Power Platform environments. Again, that's similar to providing SharePoint sites. It does not make sense to provide corporate entities with their own SharePoint sites and once the roll-out is finished, continue with enforcing Governance policies. It's a bit like handing the keys of a shiny new Ford Mustang to a novice driver and then continue with thinking about demanding a valid driver's license.
Recommended by LinkedIn
I am trying to say this: very similar to rolling out SharePoint or Teams, rolling out Power Platform environments requires a dedicated plan on how corporate guidelines are established and enforced - and how to train the teams responsible for managing environments.
Environments and applications
Environments are also containers for apps and workflows - I think that's their main purpose. Although Microsoft announced the Power Platform as a platform for Citizen Developers, this does not mean that organizations don't need to plan how their Citizen Developers are supposed to utilize their environments. Before I became a Senior Consultant, I worked many years as a C++/C# developer. You can't just go ahead and develop an app, perform a little bit of developer testing, and publish it to a large audience in an organization. That never worked! Before making Power Platform environments available to corporate entities, there needs to be a plan to use an environment to develop apps and workflows. There are a few different approaches to supporting corporate entities in terms of app/workflow development. Some organizations use dedicated environments for development and QA/UAT testing, some use a single environment for both. However, it is most important that apps and workflows are published in dedicated PROD environments only and that development and testing are kept separately.
Environments and connectors
PowerApps apps and Power Automate Flows are dealing with corporate data! A PowerApp app often utilizes data from multiple data repositories to display a user-friendly form, which allows employees to work with data from multiple repositories. But not all data repositories contain data, that can be used in apps or flows. Some of the data is hosted within databases that use a specific schema. Those data schemas can contain fields that are only used internally and should not be touched. Some data repositories contain data that is classified. In essence, organizations need to plan what data can be used with PowerApps and Power Automate. Another topic that needs to be discussed is access to external data sources or services. In other words: can an app or a flow use internal data together with external data from a repository hosted outside? Basically, this is all about Data Governance and Security. Before rolling out PowerApps or Power Automate, there needs to be a list of allowed connectors and strict policies regarding using those connectors.
Summary
It might be tempting to allow corporate entities to use Power Platform environments to create new apps and workflows - especially if there is a pressing demand from the businesses. Still, making Power Platform environments available to corporate entities requires a lot of planning and preparation - very similar to rolling out Microsoft Teams or SharePoint Online. Organizations are very well advised to create a solid plan with a team of experts (Center of Excellence). A mix of internal and external experts is highly recommended as this ensures a wide variety of ideas and approaches are presented, discussed and reviewed. The way towards a successful rollout of PowerApps and Power Automate can be rocky and labor-intensive. Still, thorough and solid planning undoubtedly pays off when rolling out Power Platform environments to the staff.