Chapter 13: Power Platform Implementation Strategies

As we move along in this chapter, you will learn to follow industry best practices and strategies for successfully implementing Power Platform applications. You will learn how to consider the deployment options available and learn to select the Power Platform topologies and environment strategies that are best suited to an organization’s needs.

Defining strategies to optimize the output of cross-functional development teams will also be explored here. Finally, you will review the test strategies and frameworks available to ensure high-quality control throughout the implementation process.

In this chapter, we are going to cover the following main topics:

• Power Platform environment and tenant configurations
• Optimizing output of cross-functional Power Platform development teams 
• Implementing effective test strategies for Power Platform solutions

Power Platform environment and tenant configurations

Power Platform environments and tenants are the base containers that host the databases, applications, and processes that make a solution. As a solution architect, you will help shape the Power Platform environment strategy. By understanding the current and future business needs and the capabilities afforded by the Power Platform infrastructure, you will propose the creation of environments to help the organization fulfill its requirements.

A tenant can host one or more Power Platform environments. A Default environment with a base Power Platform database is automatically created when a tenant is instantiated.

Selecting a geographical location for the environments

When an environment is created, a geographical location is selected. Based on regulatory requirements and the geographical location of users, the appropriate location is selected. A typical set of options presented to users when creating an environment is as follows:

Figure 13.1 – Geo-locations available when creating a new environment

In consultation with the organization’s legal and compliance teams, solution architects select the most appropriate location.

The following restrictions apply when creating new Power Platform environments:

• The India and Australia regions are restricted to organizations whose tenant is based in the same location due to tax laws. An exception may be requested for Australia.
• The US Government (GCC) is restricted to US government-associated organizations only.

Once an environment is created, you may review its geographical location within the Power Platform environment list.

Figure 13.2 – Viewing the geographical location of environments

Solution architects work with the business to select the geo-location for environments based on the following criteria:

• Geographical proximity to the uses – the closer the users are to the environment’s location, the lower the latency and the faster the system performs.
• Compliance with regulations and company policies – the organization may be bound to store its data within specific geographical boundaries.

Once an environment is created, it is not possible to change its location using the Power Platform admin center. Migration of an environment’s geographical location may be requested. However, this process is not generally available and may take over ten days to complete. For that reason, it is essential to carefully select the location when the environment is created.

Reference Documentation

Please refer to the following documentation for details on migrating environments to a new geographical location: https://docs.microsoft.com/power-platform/admin/geo-to-geo-migrations.

Deciding on a Power Platform environment strategy

Power Platform implementations tend to use multiple environments to separate components under development from the user testing and production systems. Additionally, Power Platform solutions may split environments by functional area, business applications, and geographical distribution.

A typical Power Platform implementation may be distributed across environments.

Separation of development, test, and production activities

The minimum recommended set of Power Platform implementation environments are development, test, and production instances.

Figure 13.3 – Minimum recommended set of environments

Having these three base environments allows for development and support activities without affecting production systems. Testing can also be performed in a controlled production-like environment separate from the development instance.

Separating the development environment from the main deployment base is sometimes helpful, depending on the size of the implementation team. A deployment master environment that only contains components ready for deployment prevents unwanted or unfinished functionality from entering the test and production environments. This environment strategy is illustrated in the following diagram:

Figure 13.4 – Using a deployment master environment to manage work in progress

When a project is working on multiple streams of functionality, it can sometimes be beneficial to split the development environments, allowing different teams to work on their own functional area, unit testing, and deploying as and when the features become available. The following diagram illustrates two workstreams developing in two separate environments, which then merge functionality into the deployment master environment:

Figure 13.5 – Splitting work streams across development environments

Deciding on the best environment strategy for managing the development and deployment phases will very much depend on the team size and the functionality being built. Solution architects weigh the benefits additional environments bring to the project versus the deployment and dependency management overheads they present, and then select the simplest option that will fulfill the goals of the project.

Opting in for Early Upgrades in Development Environments

It is often helpful to test upcoming Power Platform updates in a development or test environment before release into production. Separate development and test environments allow solution architects to select these for early access to updates, enabling the organization to pre-empt any capability or upgrade issues and carry out any required changes before release into production. The following document describes the steps to allow early access updates: https://docs.microsoft.com/en-us/power-platform/admin/opt-in-early-access-updates.

Separating business applications across environments

When an organization requires a wide range of applications built using Power Platform (and Dynamics 365) components, splitting applications into separate environments is sometimes helpful. You would look to split applications across environments where sharing by these applications is minimal.

Their business requirements and domains vary sufficiently to warrant a clear distinction in their functionality and data.

The following diagram illustrates different business requirements that have been split across two sets of environments. The first set covers the customer Onboarding Application, while the second set of environments includes a separate Sales Application.

Figure 13.6 – Splitting business requirements and applications across environments

This split of functionality across environments simplifies the deployment and support processes and reduces the risk of functional changes from one application affecting the other.

Separating master data environments

Organizations may look to manage a specific set of data in a centralized database, often titled master data. The data may be a product catalog, a collection of price lists, a central customer database, or various other types of data. When there is a clear requirement and mandate for the business to manage this data centrally within a purpose-built data and application, Power Platform can put forward a solution in the shape of an environment dedicated to the hosting and management of master data.

This master data environment may then be used by various other applications (Power Platform-based or otherwise). The following diagram illustrates two Power Platform applications using a central master data environment as a source:

Figure 13.7 – Using a master data environment within a Power Platform implementation

A connection with a master data environment may be carried out using the various integration capabilities within the Power Platform framework, including virtual tables, Power Automate cloud flows, and the Dataverse API.

Using multi-environment strategies to secure Power Platform applications

Using multiple environments to separate applications or business domains provides an additional layer of security. Each environment hosts its own Dataverse database, and access is controlled through separate AD security groups, and security roles.

Figure 13.8 – Increasing security by separating applications across multiple environments

Deciding whether to enhance security by creating additional environments usually considers the type of user accessing the system; for example, an organization may want to separate systems accessed by the public from their internal backend applications. Solution architects weigh the benefits that additional security would provide versus the build and maintenance overheads of having additional environments to take care of.

Using multiple environments for scalability

Power Platform environments are bound by service protection and database limits. When working with high-volume or high-throughput solutions, solution architects consider the benefits of having a separate environment to handle these activities that push the platform to its limits. Separating these demanding services from the organization’s other Power Platform applications helps reduce the risk of impacting users with high-throughput loads of data.

Sandbox versus Production

Power Platform environments may be configured at either Sandbox or Production level. Typically, non-production environments are configured using the Sandbox configuration to reduce operational costs. Production environments offer enhanced capabilities, including automated backups going back for a month. It is possible to switch between a Production configuration and a Sandbox configuration, but note that changing from Production to Sandbox will result in losing backups older than a week.

Managed versus unmanaged solutions

As a general rule, managed solutions should be restricted to development environments as using them in target environments could result in orphaned components being left behind when deleted from the source. Managed solutions are therefore recommended when importing into target environments such as QA, UAT, preproduction, and production.

For additional details on the differences between managed and unmanaged Power Platform solutions, please refer to the following document: https://docs.microsoft.com/power-platform/alm/solution-concepts-alm#managed-and-unmanaged-solutions.

Optimizing the output of cross-functional Power Platform development teams

Solution architects have a pivotal role within a Power Platform implementation. Their wide range of knowledge and experience can be leveraged to guide team members to deliver a project through the most optimal route possible. To successfully deliver a project, solution architects engage in the following activities.

Understanding the team’s capabilities

Solution architects identify the team member’s core competencies. These may be either functional, technical, knowledge in a specific type of Power Platform application, or a focus on integration-related activities.

Understanding the key capabilities facilitates the following activities:

• Distributing work optimally across team members

Once the team’s core skills are understood, solution architects work optimally with the business to help distribute the implementation work. This allows experts on a specific subject area to focus on delivering the solution.

In consultation with the business, work will sometimes be distributed to team members that are being up-skilled in a particular implementation area (for example, training junior team members to work on Power Apps Portals applications). These team members would typically require support to complete the implementation tasks, which is the subject of the next section.

• Supporting team members where needed

Team members will often benefit from the support of a solution architect or one of their peers to complete implementation tasks. Solution architects identify team members who need assistance, typically through daily standup or implementation reviews.

• Adjusting as needed

There may be instances where the original work allocation may not be suitable. Team members may find specific tasks beyond their capabilities or desired career path. Solution architects identify areas that need adjustment and re-route the work to alternative team members to maintain overall team efficiency.

Implementing effective test strategies for Power Platform solutions

Testing Power Platform implementations is another crucial part of the development life cycle. Solution architects work with test managers to ensure a test strategy is in place, including one or more of the following activities.

Manual testing

Manual validation of a solution is often the simplest form of testing and the most frequently used as it is easily accessible to standard Power Platform users. The system is put through its paces by running through the application, website, or process to validate its performance and compliance with the business requirements.

Solution architects work with test managers to ensure tests are carried out systematically. Azure DevOps test plans help teams drive internal quality by providing a test management solution where user acceptance criteria, test cases, and results may be tracked. Please refer to the following document for full details on using Azure DevOps test plans: https://docs.microsoft.com/azure/devops/test/overview?view=azure-devops.

Automated tests

Automated testing requires the configuration of tools that simulate the steps carried out by users on an application. The following are a few examples of how automated tests may be configured for Power Platform applications:

• Model-driven apps automated testing

Model-driven app testing may be automated using frameworks like EasyRepro. These tools allow testers to create scripts that run the application user interface, simulate user actions, and validate that the application’s output matches the business requirements.

The following link provides additional details on the EasyRepro framework for automated testing of model-driven apps: https://github.com/microsoft/EasyRepro.

• Power Apps portals automated testing

Power Apps portals are websites that may be tested using standard web application test tools available in the market. Typical automated tests will focus on simulating user interaction with the application frontend and performance benchmarking of the portal.

• Canvas apps automated testing

Power Apps Test Studio provides a means of performing automated testing. The following link provides additional details on Test Studio for canvas apps: https://docs.microsoft.com/power-apps/maker/canvas-apps/test-studio.

Load tests

Load testing involves the generation of traffic or actions on an application to validate its performance under load. Typically, load tests are carried out on public-facing portals to ensure the user experience will be acceptable to customers and end-users.

Power Pages and model-driven apps may be tested using web application testing tools available on the market. Note that you may need to notify Microsoft before running load tests on Power Platform applications.

Penetration tests

Penetration tests (pen tests) aim to detect security gaps in an application or service. These tests are typically carried out by specialist teams dedicated to the task. The results of pentests are usually a set of items graded by severity. Solution architects review the pentest results and action the areas that fall within the implementation team’s control. Product-related security gaps are typically reported to Microsoft support for resolution.

Summary

This chapter has taught you the benefits of having a multi-environment strategy, from development to production environment considerations, through to the security and scalability benefits of having separate environments per application or domain. You have also learned about optimizing team output and general Power Platform testing considerations. This understanding will help you make the right decision when creating the base environments and give the project the best chance of success thanks to an optimal development strategy.

In the next chapter, you will learn how to leverage Azure DevOps’s task management, source control, and release management capabilities.