Power Platform architecture overview

The Power Platform architecture comprises four key components, the environments and tenants that host these components, and the security capabilities used to control access.

Before delving into the Power Platform components, it is important to understand the data management framework that underpins the majority of Power Platform implementation. Dataverse is the foundation of most Power Platform implementations and is the first topic for our architecture overview.

Dataverse, the foundation of Power Platform data-based applications

Dataverse is a configurable business application data store with advanced processing capabilities and the foundation of most Power Apps-based solutions. Previously known as the Common Data Service, it consists of a relational database made up of tables and fields. Dataverse is configured using a graphical user interface (the Solution Explorer), and a wide range of processing capabilities, APIs, and security features. Dataverse includes a wide range of integration, security, and business process logic features.

The following diagram illustrates the key Dataverse components and interactions:

Figure 1.3 – Key Dataverse components and interactions

The flexible and configurable nature of Dataverse, combined with the wider Power Platform capabilities provides a unique opportunity to solve business problems for a virtually unlimited set of use cases. In the chapters that follow, you will learn how to design Power Platform solutions that make the most of Dataverse’s capabilities.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/powerapps/maker/data-platform) for further information on Dataverse capabilities and configuration options.

The four key Power Platform components

The Microsoft Power Platform is made of up four key components, each delivering powerful capabilities on its own; combined, they provide a compelling framework for the creation of advanced business applications. The four key Power Platform components are as follows:

• Power Apps
• Power Automate
• Power BI
• Power Virtual Agents

An overview of each of the four Power Platform components follows.

Power Platform component 1 – Power Apps

Power Apps makes up one of the five key components within the Power Platform architecture. Model-driven apps, Canvas apps, Power Pages, and Power Apps Portals are the four types of applications available via this low-code/no-code Power Apps framework. All Power Apps are managed via the https://make.powerapps.com portal, which is illustrated in the following screenshot:

Figure 1.4 – Screenshot listing Power Apps in a Power Platform environment

A summary of the three different types of Power Apps available is as follows:

• Model-driven apps are a key component of a Power Platform implementation. They are the user-facing portion of a Dataverse database. The following figure illustrates a simple model-driven app (top) and the corresponding model-driven app editor (bottom):

Figure 1.5 – Screenshot of a model-driven app next to its editor page

Web and mobile users interact with model-driven apps through the web or dedicated mobile applications. The diagram that follows presents a high-level architectural view of the component:

Figure 1.6 – Model-driven apps architectural overview

• Power Pages are internet-facing websites that leverage Dataverse capabilities to present a rich and customizable web experience. The administration section includes default templates for typical requirements such as customer service, partner management, employee self-service, and community portals. These default templates may be extended, or complete custom portal applications may be created depending on the organization’s requirements. The following screenshot illustrates the Power Pages editor:

Figure 1.7 – Screenshot of the Power Pages editor

The diagram that follows presents a high-level architectural view of the component:

Figure 1.8 – Power Apps portal architectural overview

Power Pages are an evolution of Power Apps Portals, providing a superset of the Portals capabilities, including new low-code capabilities and out-of-the-box templates.

• Power Apps Portals are the predecessors to Power Pages, providing the same core functionality but lacking the additional templates and low-code editor capabilities afforded by Power Pages.
• Canvas apps are user interface (UI)-centered applications that can be used standalone or embedded into other Power Platform applications. They may be connected to a Dataverse database or other data sources to present a fully customizable UI for interacting with the underlying data. The screenshot that follows illustrates a sample canvas app and its editor:

Figure 1.9 – Screenshot of a canvas app editor

All three Power Apps use Dataverse as an underlying platform and data source. The administration of usage of Dataverse databases is discussed in detail in the following sections and chapters.

Note Regarding Canvas Apps

The usage of Dataverse is optional within canvas apps, as these applications may be solely connected to alternative data sources, such as OneDrive or SharePoint, without the need for a Dataverse database.

The diagram that follows presents a high-level architectural view of the component:

Figure 1.10 – Canvas Apps Architectural Overview

In the chapters that follow, you will learn how to design leading-edge business applications that benefit from the extensible and rapid development afforded by the three Power Apps.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/powerapps/) for full details on Power Apps capabilities.

Power Platform component 2 – Power Automate

Power Automate is another key component within the Power Platform architecture. It provides a no-code/low-code solution for business process automation.

• Cloud flows provide a graphical user interface to build advanced business logic to suit exacting organizational requirements. Integrations with other Power Platform applications and external third-party systems are achieved through an easy-to-use point-and-click editor.

The following screenshot shows a simple Power Automate cloud flow being edited:

Figure 1.11 – Screenshot of the Power Automate cloud flow editor

The two key components of a cloud flow are the trigger (the action that will initiate the process) and one or more actions that will be executed when the flow runs.

Cloud flows may be triggered manually (for example, a user presses a button) or automatically (a record is created). There is a wide range of cloud flow triggers available. The key Dataverse triggers are as follows:

Figure 1.12 – Cloud flow Dataverse triggers

The wide range of available cloud flow actions provides solution architects with a powerful toolset for the automation of business processes and rapid integration with several Microsoft services and third-party APIs. A full list of Power Automate connectors is documented on the Microsoft documentation page titled Connector reference overview ().

The screenshot that follows illustrates a subset of the actions available when using the Dataverse connector:

Figure 1.13 – A selection of cloud flow Dataverse actions

The diagram that follows presents a high-level architectural view of the component:

Figure 1.14 – Cloud flows architectural overvie

• Desktop flows are designed to automate rule-based tasks on a user’s workstation. They provide a wide range of conditions and actions that interact with UI elements, Excel files, web browsers, and various other systems typically available in a user’s workstation.

The following screenshot illustrates a simple desktop flow being edited:

Figure 1.15 – Screenshot of the desktop flow editor

Cloud flows and desktop flows provide a rich toolset for business process automation. In this book, you will learn how to create architectural blueprints that leverage this powerful toolset.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/power-automate/) for detailed instructions on the creation and administration of Power Automate flows.

Power Platform component 3 – Power BI

The third Power Platform component discussed in this book, Power BI is an analytics and reporting framework that connects to various data sources, to present high-impact visuals. Advanced data visualizations can be quickly generated from multiple data sources and presented through a range of software services. The diagram that follows presents a high-level architectural view of the component:

Figure 1.16 – Power BI architectural overview

Power BI reports are edited using either the Power BI desktop app or the web version of the report editor. The following screenshot presents a Power BI report in the process of being edited:

Figure 1.17 – Screenshot of the Power BI report editor

Working through the implementation scenarios discussed in this book, you will learn how to plan and design Power BI-based solutions to solve an organization’s most complex reporting business requirements.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/power-bi/) for detailed information on Power BI capabilities, data modeling, development of Power BI reports, and best practice guidance.

Power Platform component 4 – Power Virtual Agents

Organizations streamline costs and provide their customers with a responsive user experience using Power Virtual Agents. Users interact with the platform through various channels, including web chat and SMS messaging, benefiting from advanced routing capabilities.

The following screenshot illustrates a Power Virtual Agents chatbot test facility:

Figure 1.18 – Screenshot of a Power Virtual Agent being tested

Power Virtual Agents can be embedded within websites and deployed to entities including Facebook, Slack, Twilio, email, and mobile apps. The following diagram provides an overview of the Power Virtual Agents architecture:

Figure 1.19 – Power Virtual Agents architectural overview

In this book, you will learn how to define customer interaction strategies that leverage the cost-saving and operational benefits of Power Virtual Agents.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/power-virtual-agents/) for step-by-step guidance on the creation of Power Virtual Agents.

Other Power Platform building blocks

The previous sections described the four key Power Platform components. These components are underpinned by two additional building blocks:

• Data connectors

Data connectors facilitate integrations between Power Platform components and external systems, solving previously complex integration problems with just a few clicks. Connections to Dataverse, SQL databases, SharePoint files, and various other sources of data are easily accessible through the use of data connectors.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/connectors/) for further information on available Power Platform connectors and their capabilities.

• AI Builder

A pivotal tool in the Power Platform arsenal. AI Builder provides a no-code solution for the creation of AI-powered automation processes.

Further Reading

Please visit https://docs.microsoft.com/en-us/ai-builder/ for full instructions on using the AI Builder for Power Automation, Power Apps, and other Microsoft services.

In the coming chapters, you will navigate through the use cases for these two building blocks, and design architectural blueprints to maximize an organization’s investment in the Power Platform and the wider Microsoft ecosystem.

Environments and tenants

Power Platform applications exist within an environment. In turn, environments are hosted within a Microsoft tenant. A Power Platform environment is made up of the following components:

• Name: A textual label for the environment
• Location: The geographical region where the data and configuration will be stored within Azure data centers
• Admins: The users that will administer and configure the environment
• Security groups: Controls that define who can access specific data records and application features
• Apps: Model-driven apps, portals, canvas apps, and other applications that exist within the environment
• Flows: Power Automate components that implement business process and integration routes
• Bots: Power Virtual Agents chatbots that are configured to interact with users
• Connectors: Identifies the connections that have been configured for Power Platform and external systems
• Gateways: Components that allow the integration with on-premise applications
• Dataverse: An optional Power Platform component and data store instance used by various Power Apps, such as model-driven apps

The following screenshot presents a typical set of development, test, and production Power Platform environments:

Figure 1.20 – Screenshot of a Power Platform environments list

Multiple environments may be created to support the development and release cycles. A typical Power Platform implementation includes development, test, and production environments. They may all be hosted within the same tenant or spread across a multi-tenant architecture. In this book, you will learn how to decide on the best environment and tenant strategy to achieve the organization’s goals.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/power-platform/admin/environments-overview) to review the options available when managing Power Platform environments.

Security

The security of data hosted within a Power Platform environment is enforced through the following layers:

• Azure AD

The cloud-based Active Directory solution. Users are configured for access to specific resources, assigned security groups, and authentication policies.

• Licenses

Assignment of licenses to Azure AD users grants them access to specific Power Platform applications, providing an additional access security layer.

• Environments

Assigning security groups to Azure AD users sets them up for access to the applications within environments associated with those security groups. An additional security layer for Power Platform applications and data sources.

• Data loss prevention policies

Data loss prevention policies define the types of connectors and inbound/outbound data privileges afforded to users of Power Platform applications.

• Security roles

Security roles provide granular control over the data tables and columns stored in the Power Platform Dataverse. They further control access to specific features within Power Platform applications.

• Encryption

Power Platform applications benefit from the encryption of data both in transit and at rest.

The various security features and considerations will be discussed in more detail in the upcoming chapters, where you will learn how to define a security concept document to satisfy an organization’s strict requirements.

Power Platform application life cycle management

Application life cycle management (ALM) is a set of disciplines through which Power Platform projects can be defined, implemented, deployed, and operated through a controlled framework. It is a cyclical set of activities and processes through which Power Platform requirements are captured, broken down into tasks, developed, tested, and deployed. Once deployed, the operation of the system is managed and monitored, and the next cycle is optimized based on lessons learned.

Figure 1.21 – Power Platform ALM activities and key components

ALM is the key to the success of any Power Platform project. In the chapters that follow, you will work through a set of practical scenarios, configuring Azure DevOps to manage the life cycle of a Power Platform project, configuring task management, source control, build, unit test, and automated deployment pipelines, and monitoring capabilities.