Chapter 12: Validating the Solution’s Design and Implementation

In the previous chapters, you learned how to lead the Power Platform solution design process. Using descriptive visual designs, component reuse patterns, and time-tested automation strategies, you can build a solid foundation for your implementation. You also learned how to translate complex requirements into effective data models, develop resilient integration strategies, and define the solution’s security concepts.

In this chapter, you will review the output from the solution design stages and evaluate its implementation for compliance with Microsoft Power Platform best practices and its close alignment to the organization’s requirements.

The implementation will be regularly assessed for adherence to security concepts and conformance with API limits. You will also learn how to resolve integration and automation conflicts through a systematic approach to problem-solving.

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

• Continuous review of detailed designs and their resulting implementation
• Validating compliance with the defined security requirements
• Implementing solutions that work within Power Platform API limits
• Resolving business automation conflicts
• Resolving integration design conflicts

Continuous review of detailed designs and their resulting implementation

As the implementation progresses, detailed designs are created to cover the functional and technical areas. Solution architects review these technical designs to ensure adherence to best practices and the design principles set out at the beginning of the project.

Validating the Power Platform detailed designs

Validating Power Platform designs typically involves running several reviews, including best practices, company policy, and regulatory considerations. Solution architects ensure the designs are compliant, working with various teams within the organization to ensure the designs are ready for implementation.

The following diagram illustrates the various stages in a solution design and review process:

Figure 12.1 – Example Power Power Platform design validation process

The order in which these reviews take place is flexible and subject to change, depending on availability. Depending on the solution’s size and complexity, some review stages may not apply. Solution architects work with the business to drive the following solution design stages through to completion.

1 – adherence to best practices

The design documentation is reviewed to ensure it adheres to published Power Platform best practices. The review process aims to identify any design elements that do not meet best practice standards and need to be adjusted, changed, or replaced.

Design documents are also reviewed to ensure they take into account the nine pillars for great Power Platform architecture (please refer to Chapter 1, Introducing Power Platform Solution Architecture, for details).

Reference Documentation

The latest Microsoft Power Platform best practices are available in the following documentation:

Power Platform Best Practices and Guidance: https://docs.microsoft.com/power-platform/guidance/

Dynamics 365 Development Best Practices: https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/best-practices-sdk

2 – adherence to development guidelines

In the initial phases of a Power Platform project, solution architects define and release the development guidelines to be used by the build team. This document is usually published on a Team Wiki page for ease of access. The following screenshot illustrates the location of an Azure DevOps Wiki created as a source of reference for consultants and developers:

Figure 12.2 – Example development guidelines Wiki in Azure DevOps

For details on setting up an Azure DevOps Wiki, please refer to the following online documentation: https://docs.microsoft.com/azure/devops/project/wiki/wiki-create-repo.

Design documents produced by the team are reviewed for adherence to the project’s development guidelines. Deviations from the defined standards can then be corrected, resulting in a cohesive implementation.

A development guidelines review is typically carried out by someone other than the main author for a given design document. A solution architect or consultant with sufficient knowledge of the technology in question to make an informed assessment.

3 – compliance with company policies

During the requirements capture phase, company policies affecting the Power Platform implementation would have been identified. The detailed design documentation is reviewed to ensure that all company policies have been taken into account. This covers areas such as storing and processing personal information and user access restrictions.

Solution architects work with business analysts and system owners to understand how to identify the company policies that apply to the solution and ensure the design complies with those policies.

4 – compliance with legal requirements

Similar to the review for adherence to company policies, any legal requirements that are identified during the requirements capture and analysis phase are taken into account during the detailed design process. The design review aims to ensure the legal requirements are catered for and address any gaps in the design.

Conclusions on the design validation process

Solution design reviews help get the project off on the right foot, provide a level of confidence in the solution, and reduce the risk of refactoring if a component is found to be non-compliant with a regulatory requirement at a later stage in the project. Now, let’s look at the process of reviewing the actual implementation of a Power Platform solution.

Validating and reviewing the Power Platform implementation

Solution architects define the implementation review process early on in the project. The review process may include peer reviews, unit test requirements, code reviews, and source code pull request strategies. Depending on the project’s size, solution architects may be directly involved in carrying out the implementation reviews.

The following subsections describe the typical implementation review processes for a Power Platform implementation.

1 – peer reviews

The larger the implementation team, the more comprehensive the range of skills and expertise the team members will have. Peer reviews provide a means of managing the build process, reducing the risk of implementing a solution that requires rework or refactoring to meet industry best practices and the project’s development guidelines. Solution architects define the peer review process that consultants and developers use when completing a task or component.

Using this process, functional team members review each other’s work on completion, cross-checking it with the following:

• Compliance with the project’s development guidelines and naming conventions for tables, columns, views, and forms
• Adherence to the detailed designs

The reviewer will typically reference the Development Guidelines Wiki that was created at the beginning of the project to ensure the implementation follows it closely. The following screenshot illustrates a typical Development Guidelines Wiki built using Azure DevOps:

Figure 12.3 – Example Development Guidelines Wiki built using Azure DevOps

2 – code reviews and pull requests

Code reviews serve a similar purpose to functional peer reviews, helping to identify areas of the build that require changes to meet development guidelines and best practices. Solution architects define the code review and pull request (where applicable), helping developers build supportable and extendable code.

The following areas are typically covered in the code review process:

• The code is necessary. Identify if the functionality could be implemented without code and favor the low-code option.
• The code is structured following project guidelines and a recognized development standard (for example, SOLID development; please search for .NET SOLID development for details).
• The code meets project guideline style conventions.
• The code’s logic is sound.
• Code duplication is kept to a minimum, if at all.

The peer reviewer will typically place comments on a pull request. When using Git as a source control repository, you will likely want to define a branching and pull request strategy. The following diagram illustrates an adaptation of GitFlow tailored for Power Platform development (please search for GitFlow for details on the concept behind the GitFlow branching model for Git):

Figure 12.4 – Example Git branching and merging strategy for Power Platform development

The Git branching and merging strategy in the preceding example leverages feature branches for parallel implementation of Power Platform components, together with Power Platform’s solution-specific branch, to reduce/remove the risk of merge conflicts. While this is not always the ideal source control solution for all Power Platform projects, the development team must have a clear directive so that code is developed, managed, and reviewed consistently.

3 – unit test coverage

As the application grows, so will the unit test requirements. Depending on the nature of the application, the code base may grow. In addition, specific projects will benefit from UI unit tests on Model-Driven Apps and Power Apps Portals.

Solution architects review the implementation regularly, ensuring a sound unit test strategy is followed throughout the build.

Solution architects and test managers compare the current testing process against the test strategies defined during the design process (please refer to Chapter 8, Leading the Power Platform Design Process) and recommend adjustments or additional coverage if necessary.

4 – overall implementation review

Carrying out an overall implementation review at specific checkpoints in the implementation helps solution architects steer the solution toward the design envisioned at the beginning of the project.

These checkpoints involve taking stock of all the components that have been configured in the following areas:

• Dataverse configuration: Review the tables, columns, processes, and plugins that have been built to date, and steer any areas that may need adjustments.
• Dataverse security: Review the security roles that have been configured to match the designs and use cases.
• Model-Driven Apps: Review the configuration of Model-Driven Apps forms, views, menus, and related functionality, confirming that the application is easy to use and fulfills the objectives.
• Canvas Apps: Similar to Model-Driven Apps, reviewing the applications is easy and fulfills the objectives.
• Power Automate: Review the implementation for compliance with implementation guidelines and best practices.
• Power Pages: Review the configuration of Power Apps Portals.
• Power BI: Review the configuration and integration of Power BI to meet the implementation guidelines.

Conclusions on the implementation review process

Reviewing how the Power Platform solution is being implemented is critical to the success of the project. Regular health checks help keep a solution on track and reduce the risk of refactoring and defects.

In the next section, we will review how technical designs may be reviewed for compliance with security requirements.

Validating compliance with the defined security requirements

Solution architects revise Power Platform’s detailed designs to address security requirements. This involves reviewing authentication strategies, storing credentials and secrets, and conditional access rules, all of which will be discussed in the following sections.

Validating Dataverse security for compliance with best practices and guidelines

The security concept document will have defined the model that describes the security within a Dataverse environment. Solution architects review the implementation of the security model to ensure compliance.

Validating authentication strategies

This involves reviewing connections from Power Platform applications and services to systems that require authentication. The security and integration designs will set a standard for the authentication protocols and minimum requirements for outbound connections.

Connections from external systems to Power Platform services will also require authentication. These connections are reviewed for compliance with the minimum authentication security strategy set out in the designs.

Users or services using an authentication strategy that is not compliant with the designs need to be closely reviewed and potentially updated to use an approved authentication method.

Validating storage and processing secrets

Authenticating with external systems typically requires storing secrets or credentials that are used for authentication purposes. Safely storing, retrieving, and managing these credentials is critical for the secure operation of Power Platform applications.

Solution architects validate the following areas of the implementation:

• Securely storing credentials: The location that’s used to store credentials and secrets is carefully selected during the design stages. These decisions bear in mind the current and future estate within the organization and restrictions imposed by company policies (for example, the availability of an Azure subscription and Azure Key Vaults). Solution architects validate that the solution has been built using the selected credential storage locations.
• Securely retrieving credentials: Power Platform applications that integrate with external systems may need to access credentials stored in a safe location. The action of retrieving those credentials may compromise the security of their storage location unless proper care is taken during the implementation. Retrieving credentials using an application key/secret that is accessible to a wide range of users can result in all the credentials in the accessed store being compromised. Solution architects review the detailed designs and ensure that their implementation complies with the overall project security concepts.
• Securely managing and rotating credentials: The project security concept will have defined processes for rotating credentials and secrets if appropriate. Solution architects validate that the Power Platform solution has been built to facilitate the cyclical update of these credentials. The normal functions of the application are unaffected by this process.

Monitoring for security compliance

As the implementation moves forward, new components will be built by the various team members. These components are typically developed while following the principles defined in the design documentation. An important part of the solution architect’s role is to review the implementation of these security concepts and ensure the following:

• Outbound integrations are stored securely: Connections from Power Automate, Dataverse plugins, and Canvas Apps store and retrieve credentials for target systems securely (using Key Vault where applicable).
• Plugin configuration security: If credentials are stored in Dataverse plugin-secure configuration strings, these are only accessible to authorized staff members. Note that all Dataverse system administrators can read the plugin’s secure configuration settings.
• Adherence to data loss prevention policies: Changes to data loss prevention policies may result in processes being deactivated without notice. Solution architects are aware of upcoming DLP policy changes and can assess the impact they would have on Power Automate processes.

Implementing solutions that work within Power Platform API limits

Power Platform applications are required to work within a set of API limits. These limits are in place to prevent the cloud-based platform from being overused and to provide a reliable service to all its users. You will typically assess the projected consumption during the design stage. Solution architects review detailed designs to identify areas that may lead to a Power Platform component breaching API limits.

User API limits

Users interact with Dataverse either via a Power App (for example, a Model-Driven App) or via the Dataverse API, as is the case with application users. The published request limits change from time to time (please visit https://docs.microsoft.com/power-platform/admin/api-request-limits-allocations for the latest allocation limits).

Licensed user request limits

Depending on the type of license, users will be presented with different API limit allocations. Solution architects review the licensing strategy to ensure the standard allowance will be sufficient to cater to the projected API requests during the regular operation of the Power Platform application.

Non-licensed user request limits

Non-licensed application users have a different set of allocation limits. Solution architects and implementation consultants use non-licensed application users when connecting external services or applications to Dataverse to benefit from the added flexibility and security they provide.

Dataverse service protection API limits

The Dataverse API is bound by service protection limits that are designed to maintain a reliable service for all users. Solution architects review the detailed designs to identify areas where these limits may be breached (for example, integrations that require millions of records to be created/updated in a short space of time may be throttled by the Dataverse API’s limits). Solution architects review the detailed designs and identify components (or groups of components) likely to breach the API limits. The plans are then adjusted to work within limits (for example, distributing the API requests across multiple licensed users, extending the data import load window, or changing the load altogether to reduce throughput).

Reference Documentation

The latest Dataverse service protection API limits are available in the following documentation: https://docs.microsoft.com/power-apps/developer/data-platform/api-limits.

Power Automate limits

Cloud Flows are bound by a set of API and action limits. Solution architects review detailed designs to ensure the resulting processes perform within the purchased API capacity.

For example, a Cloud Flow containing a loop that typically runs 1,000 times per execution and results in 20 actions per loop cycle, which would result in 20,000 action steps, potentially breaching the daily allocation. They may be subject to throttling.

Reference Documentation

The latest Power Platform API limits are available in the following documentation: https://docs.microsoft.com/power-automate/limits-and-config.

Resolving business automation conflicts

Business automation processes may conflict with each other, especially as the application grows in size and complexity. Solution architects review the business automation design, identify areas where these conflicts may occur, and make adjustments to the designs to prevent these.

A typical example would be a business process that relies on a record moving through a sequence of statuses. Individual processes may guide the record’s status, depending on their triggers and logic. As the application grows, so does its processes. The implementation team may lose visibility over the processes controlling the status of the record. In those instances, solution architects define a business automation process that is coherent and consistent throughout. A potential solution could be to implement state-machine business logic that ensures a record is always in the correct status.

Systematically problem-solving automation conflicts

Business automation conflicts can be difficult to troubleshoot due to the number of moving parts involved in a typical Power Platform business application.

Identifying race conditions

When more than one process or multiple instances of the same process run in parallel to update a given data item, this gives rise to what is known as a race condition. These, in turn, can result in unexpected results or data that is out of date.

To resolve race conditions, you must systematically review each process that writes to a given data item (for example, check all processes that update a given column). These may be Power Automate processes, plugins, or external systems updating Dataverse.

The asynchronous nature of Power Automate Cloud Flows can often lead to such scenarios if they’re left unchecked. There are instances where controlling the concurrency of the Cloud Flow is the only way to prevent a race condition. In those instances, you may look to change the Cloud Flow trigger, setting the degree of parallelism to 1, as shown in the following screenshot:

Figure 12.5 – Setting the Cloud Flow degree of parallelism to 1

Note Regarding Cloud Flows and Their Degree of Parallelism

Once a Cloud Flow trigger’s degree of parallelism is set, it cannot be unset. You will, however, still be able to change its value from 1 to 100.

Another important consideration when setting the degree of parallelism is that setting it to 1 will considerably reduce the Cloud Flow’s performance, as it will only be able to service one instance at a time.

Review processes for updating a table or column

Running a dependency check on a column will typically list processes that are either reading or writing to that column.

For plugin-based processes, a scan of the code base for column usages can also yield a list of potential components that may be at fault.

Note

Using EarlyBound code generation to automatically create a type-safe Dataverse structure in .NET code can be an invaluable tool for identifying columns are tables used by plugins. The type-safe nature of the code will make it easy to find all references to a column.

Please refer to the following documentation for details on Early Bound classes https://docs.microsoft.com/power-apps/developer/data-platform/org-service/generate-early-bound-classes.

The following XRM Toolbox plugin provides an easy means of generating an Early Bound class structure: https://dynamics-chronicles.com/article/xrmtoolbox-presentation-early-bound-generator.

Resolving integration conflicts

Solution architects review the designs and implementation of Power Platform integrations to identify areas where they may be a conflict between them or other business processes. The actions and domain for each integration are reviewed individually and in combination with different integrations to identify potential clashes.

A typical example of an integration conflict is enriching contact data from two different sources:

• One integration may be responsible for updating a contact’s address and contact details.
• A second integration may also update contact details, overwriting the first integration’s data.

The result is a Dataverse contact with data in an inconsistent state.

The following steps will help you identify and resolve integration conflicts:

• Review the integration designs to identify which interfaces interact with the affected data item.
• Review the actual implementation, scanning for Power Automate Cloud Flows, workflows, plugins, and actions (and possibly JavaScript custom code) that interact with the affected data items. This may be done via a Dataverse dependency check on a column or table and by scanning the source code for the relevant columns if applicable.
• Update the design, making adjustments to ensure conflict does not occur. For example, suppose two interfaces are writing to the same contact address field. In that case, a process could be put in place, providing priority to interface A, which would result in updates from interface B being ignored. Alternatively, the design could be changed in agreement with the product owners, resulting in only one interface updating contact addresses, thus removing the conflict.

The integration designs and their resulting implementation are adjusted to ensure the domain and reach of each integration are clearly defined, and that any overlaps in data jurisdiction are addressed.

Systematically problem-solving integration conflicts

One key tool in resolving integration conflicts is a log. When an integration logs every request and response sent to and from an external service, it is possible to identify integration problems much more quickly than examining the changes to a dataset.

Chapter 10, Power Platform Integration Strategies, discussed the benefits of using a custom log table to audit the dialogue between Power Platform and external applications. This logging mechanism can be used to ascertain the events that took place leading to an incident and help guide a solution, which may be any of the following:

• Updating the outbound integration process
• Updating the calling integration client
• Applying a data fix if the issue is understood as an isolated one-off incident

This section provided a high-level overview of Power Platform integration conflict resolution. Please refer to Chapter 10, Power Platform Integration Strategies, where we discussed integration strategies in detail, for more information.

Summary

This chapter taught you to review the detailed designs and implementation for compliance with best practices, development guidelines, security requirements, and legal requirements. You also learned how to assess the API request usage for a Power Platform implementation and the adjustments that can help reduce the risk of over-consumption. These review tasks are essential for steering the implementation toward the vision set out in the early phases of the project.

In the next chapter, you will learn how to define solid Power Platform implementation strategies, including configuring Power Platform tenants and organizations, leveraging Azure DevOps, optimizing team output, and defining effective test strategies.