Home

Microsoft Power Platform For Dummies Cheat Sheet

|
Updated:  
2024-12-09
|
Microsoft Copilot For Dummies
Explore Book
Buy On Amazon

The Microsoft Power Platform is a suite of applications that offers low-code and no-code development tools organizations can use to streamline and automate business processes. Collectively (and when integrated properly), the Power Platform suite of applications works together to support business transformation. Following is a description of the applications contained in the Power Platform, and some details about how each application functions as part of the suite:

  • Dataverse: Starting your journey with each of the Power Platform applications requires one essential element: data. At the heart of the Power Platform is Dataverse, the common data service for storing and structuring relational data. Dataverse serves as the backbone for capturing and retaining user inputs across the platform's apps.
  • Power Apps: The first step in the low-code/no-code journey to business automation is to create a mechanism for data entry. You can begin, for example, by using Power Apps to build an application that collects and manages data. Power Apps is often the primary tool businesses use to design custom applications that are tailored to their needs.
  • Power Pages: Sometimes, you want the data entered with your Power Apps applications to be available for everyone to see, not just a few users. This is when you use Power Pages to design secure, data-driven external websites. The sites you create with Power Pages can display and collect information directly from Dataverse. Power Pages presents this data in a tabular format or as embedded reports and other media objects.
  • Power BI: For data analysis, you use Power BI to transform data collected through custom apps created with Power Apps into interactive reports and insightful dashboards.
  • Power Automate: You can use Power Automate to automate tasks and processes based on the data in Dataverse, which enhances productivity and efficiency across your organization.

Choosing a Power Automate Cloud Flow type

Power Automate is Microsoft’s low-code workflow automation solution within the Power Platform. The product allows users to automate repetitive tasks, reducing the number of steps it takes to complete an activity. Power Automate offers three flow types: Cloud Flow, Desktop Flow, and Business Process Flow.

The purpose of each flow is as follows:

  • Cloud Flows: These workflows run in the cloud and can be triggered in several ways depending on the use case. Cloud Flows operate based on predefined triggers and can execute automatically, instantly based on user interaction, or according to a set schedule.
  • Desktop Flows: Commonly associated with Robotic Process Automation (RPA), Desktop Flows run on the Desktop. These flows depend on user intervention (attended) or execution by an agent (unattended). Allowing Desktop Flows to run virtually requires Power Automate Premium, as a virtual agent (bot) must execute the flow. This product is separate from Power Automate.
  • Business Process Flows (BPF): Primarily used with model-driven apps, a BPF in Power Automate guides users through a sequence of stages and steps to complete a business task. The BPF helps ensure that users follow a structured process, such as qualifying a lead or resolving a case, leading to a clear, concluding action.

Unlike Cloud or Desktop Flows, Business Process Flows focus on user interaction and can be customized based on role-based access using Dataverse. This means different users see only the steps relevant to their responsibilities. This customization ensures that the workflow adapts to the organization's needs and provides a clear path for each user, helping to ensure consistency and compliance across business processes.

Of all the flow types, you’ll likely use Cloud Flows most often—and for good reason. Microsoft supports the integration of hundreds of connectors, providing access to third-party data sources and applications within Power Automate. The key difference among the Cloud Flows lies in the automation target and the task that must be completed.

  • Automated Cloud Flows: These flows use connectors for cloud or on-premises applications to connect to specific user accounts. Once connected, the connector will communicate with the data source when triggered. For example, an automated cloud flow might send a user a text message (SMS) when a new file is added to a folder.
  • Instant Flows: These flows are triggered when a user presses a button to initiate the action. Instead of a user having to complete a task that may take ten steps manually, pressing the button triggers a sequence of events that handles the repetitive activity. Instant flows are often used for approving or rejecting a document in Teams or SharePoint.
  • Scheduled Flows: These are executed based on a known date and time to trigger an event. Examples include uploading all the files from a folder to another online site, such as SharePoint, or sending out a weekly notification to remind a team to submit their timecards.

So, which type of flow is the best to use? For most users, Automated Cloud Flows offer the most opportunities for automation in conjunction with other Power Platform applications, as they run without manual intervention. Automated Cloud Flows have an added benefit: they can instantly react to changes in data or events, streamlining processes and saving time across organizations, which other flows cannot necessarily support without manual modifications.

Building optimized entities in Dataverse

Dataverse is no different than any other data-driven solution regarding data quality. If the data is not optimized for the environment, your applications and reports won’t perform as you’d like. Each entity (table) in Dataverse can be associated with one or more forms, views, charts, and dashboards. To ensure optimal performance across each of the Power Platform applications, entities must be structured efficiently. Each entity must focus on using appropriate relationships among entities (think 1:1, 1:N, N:N), data types (strings, numbers, currency, and so on), and indexes. When designing your entities, consider their global purpose as well as how they will be used by each of the Power Platform applications. The following table breaks down the key considerations by application.

Application Considerations
Power Apps When designing your entity for a Power App application, your business objective is to focus on how the application fetches, displays, and manipulates data. Address the following to achieve optimization for a Power App with Dataverse:
  • Limit the use of calculated or roll-up fields: While they can be helpful, these field types can impact performance.
  • Index frequently: If fields are queried frequently, you should index them, especially when using field data for lookup and filters.
  • Look up relationships: Don’t reinvent the data wheel. Create a table once and then use it across many entities. Such a strategy focuses data quality, eliminates data redundancy, and ensures referential data integrity.
Power BI Power BI uses Dataverse to produce report and dashboard outputs, in most cases for real-time reporting. But when the datasets are not well designed, performance will suffer. As you consider reporting requirements, address the following:
  • Efficient relationships: Relationships between entities must be clearly defined to avoid ambiguity. That means entities should maintain a common naming convention, especially for key-based relationships. For example, you wouldn’t want one entity to have a column called State Capitals and the other to be referred to as simply Capitals. If the data has a common objective, naming consistency is critical.
  • Filtered views: Don’t import an entire entity data when only a small subset of records is applicable. Hence, you’ll take a performance hit if you download one million records versus one thousand. Instead, create filtered views that focus on targeted columns, and filter those columns with as many conditions to ensure the data is limited to just the necessary records.
  • Data aggregation: Aggregate data sources within Dataverse, don’t aggregate the data once running the reports. The result of real-time data aggregation will be poor performance for reporting, especially if the dataset contains many calculations.
  • Less DAX yields better performance: Using complex DAX formulas (Power BI’s low-code formula language, called Data Expression Language) as part of a report will slow the output of data. Instead, the calculations should be part of Dataverse. Pre-calculating outputs using Dataverse speeds up the delivery of report outputs.
Power Pages Power Pages relies on Dataverse to display dynamic content on external-facing web pages. Example content includes structured tables and Power BI-type reporting. To optimize page load, consider the following when using Dataverse entities:
  • Limit Dataverse output: While all data for Power Pages is stored in the Dataverse, more data output isn’t necessarily a good thing. Limit your output to only those fields that are necessary.
  • Don’t overcomplicate formatting: As with data output, overcomplicating formatting of your Dataverse output impacts performance.
  • Cache static data: If your site will use content often, focus on caching strategies, including the use of Content Delivery Networks, so that data that isn’t accessed often becomes a priority, as this improves load time.
  • Apply role-based security: Don’t give all users access to all data. Instead, apply role-based security enforcement. This limits the records users can see to only those datasets that they can see and edit based on permissions.
Power Automate Workflows are heavily reliant on Dataverse performance, especially when having to scour large, complex datasets. Be extra careful when it comes to querying too much data at once or instituting too many workflow triggers for the following reasons:
  • Batch records: Fewer queries to a Dataverse instance speed up performance; therefore, focus on batching records for updates. If you process records individually, you are bound to have slow data performance (like a traffic jam on a multi-lane highway)
  • Trigger when necessary: Create trigger conditions that minimize constant querying of the Dataverse instance. Instead, implement as many conditions as possible to a Workflow so that performance is optimized to just those events that require Dataverse interaction.
  • Minimize the use of actions: Using too many actions (what triggers a workflow) will reduce Dataverse performance. Only use actions with flows when necessary, and when you do use actions, avoid complex actions. That means, little to no nested loops that will keep cycling unnecessarily through a dataset.

You don’t have to figure out what works and what needs fixing in Dataverse alone. Microsoft provides you with monitoring and performance tools to review and tune your Dataverse environment. And don’t forget data that is no longer useful should be archived because less data being queried means faster ongoing performance.

By now, you should notice a few key themes across each of the applications: data quality, data integrity, and focusing on performance are essential to implementing Dataverse. If an organization focuses on how its entities handle business rules, validation, and relationships, then it is conceivable to deliver ongoing performance success with Dataverse.

Visualizing data with Power BI reports and dashboards

Power BI reports and dashboards are visualization outputs that you make available to users. Here’s how Power BI distinguishes these visualizations:

  • A Power BI report is a single or multi-page output that contains one or more data visualizations. Each page in a report includes a combination of tables, graphs, charts, and other media objects (including third-party sources such as photos or videos). Power BI reports are highly interactive, allowing users to drill down and focus on specific data points for deeper analysis. Reports often pull data from various data sources, including Dataverse, Excel, Access, or SQL Server. The key to successful report design is how the data is organized and presented to tell a story.
  • A Power BI dashboard combines your most important reports and brings them together to tell a story about an aspect of your data in a visual format. You might have many reports that show different facets of a story, but the dashboard brings all those facets together on a single page. An example of a dashboard might be sales performance across all regions for an organization, while a Power BI report tells the story of a specific geography.

Figure 1 shows an example of a well-designed Power BI dashboard. Each of the items displayed in the dashboard is a separate report. Pinning reports to a dashboard presents a holistic picture. From the dashboard shown in Figure 1, for example, you can ascertain the total amount of spend for Microsoft SharePoint Services across the U.S. Federal Government in Fiscal Year 2023 and Fiscal Year 2024, based on filtered parameters.

Figure 1: A well-designed Power BI dashboard.

Dashboards provide a concise, at-a-glance view of your data, making it easier to monitor trends, identify opportunities, and track key performance indicators (KPIs). Dashboards offer less depth and interaction compared to Power BI reports. A Power BI Dashboard is meant to provide a summarized overview of your story for those who need to understand the whole picture, not just a subset of it.

Design tips for Power BI dashboards and reports

To create meaningful dashboards and reports in Power BI, you need to be thoughtful about how you design them. Here are some key considerations:

  • Choose the right visuals. The Power BI Visualization pane offers 20+ visualization options (see Figure 2). Keep in mind that not all your data should be displayed as a bar, column, line, or pie chart. Think about the story you are trying to tell. Sometimes you want to share a discrete value; other times, you may need a table to boost the level of detail and promote understanding.
Figure 2: Visualization pane visual options.

  • Use filters and slicers. Don’t be afraid to incorporate filters and slicers so that you can drill down into the data. It’s great to see the big picture, but the most effective dashboards allow you to view a subset of data. When creating a dashboard, use filters and slicers to filter all visuals, not just one. Figure 3 shows an example of a slicer that helps narrow down the result set based on a specific classification code called a NAICS.
Figure 3: A slicer that helps filter a dataset.
  • Tell a story with your data. Your visualizations, and more importantly the data in the visualization, should tell a concise story. What is the key message you want your audience to learn about from the dashboard? Focusing on discrete metrics can help users focus on the most important insights. In the Dashboard shown in Figure 1, the focus is Fiscal Year 2023 and 2024 SharePoint Service Sales. The visualizations used consider the buyers (agencies and amount spent), contract types the sales were issued under, the geographical distribution of sales during the period, and the total amount spent across several targeted metrics. If you want to drill down into a specific purchasing code to see finer grained details, you can use the slicer to get laser focused.
  • Make it accessible. Power BI supports creating reports and dashboards that are Section 508 compliant, ensuring those users who have a visual disability including color blindness can now interpret the data. Consider design elements like color contrast, the use of tooltips, text size, and the use of alt text for images and charts.

Power BI is a versatile and powerful tool for transforming raw data into actionable, interactive insights. If you understand the difference between reports and dashboards and can incorporate the interactive capabilities available from Power BI, your ability to create compelling visualizations will drive informed decision-making.

Which Power App type is right for you?

Power Apps brings together a suite of services, namely low-code application tools and data connectors. It allows users to build applications that capture data, create rich business logic, and display relevant reports in a single location, eliminating the need for multiple tools. With Power Apps, you can develop apps in one of two ways: canvas or model-driven applications.

Canvas and model-driven apps each have distinct purposes and business advantages. The one common factor between both is their reliance on data. Based on your business requirements, it is crucial to determine which type is the best fit. Sometimes, you may need to create a hybrid application — combining the best of both worlds to meet user requirements.

Gathering requirements

When you create an application, you should start by addressing two considerations: (a) the type of data that will be stored and displayed in the app and (b) the business process automation required to meet user needs successfully. When you gather requirements, ask these questions:

  • Is there a specific type of data source the application must use?
  • Is a custom user experience and user interface (UI) more critical, or is data quality and reliability the priority?
  • How often do you intend to make changes to the application?
  • What level of reporting is needed, and how should that reporting be presented?
  • How comfortable are developers with using custom code to update the user interface?
  • Does the application require the creation of custom controls, including Power Apps Component Framework (PCF) controls, to support visualization enhancements, such as buttons, sliders, and check boxes?
  • Will the business rely on a complex workflow requiring Power Automate, or can the app utilize business process flows readily available within Power Apps?

Factoring in your use of data

Your use of data is often a key factor in deciding which application format to choose. Ask yourself where the data resides and how complex it is. Canvas apps can pull data from many sources and display those sources in a highly graphical, customizable manner, as shown in Figure 4. Model-driven apps are designed to work with Dataverse, which provides a more rigid method of handling data and user experience, as shown in Figure 5.

Figure 4: A simple canvas app (Data Entry view).
Figure 5: A model-driven app (view and form).

Using Dataverse is ideal when complex data modeling requirements, including role-based access security requirements. If Dataverse is required, then you are likely to use model-driven applications. On the other hand, if your application does not rely on Dataverse and interface customization is more important, then Canvas applications are a better fit.

Considering the user interface (UI)

If a custom user interface (UI) is a priority, you’ll want to use a canvas app, as model-driven apps are not flexible when creating a custom look and feel. Model-driven apps provide a consistent, data-rich experience and a user interface familiar to most users, as they mirror the design of many Microsoft applications. On the other hand, canvas apps allow you to create virtually any look and feel you desire. The following table compares the aspects of canvas and model-driven apps to consider before you choose an app type.

Table: Comparing Canvas vs. Model-Driven Apps

Canvas Apps Model-Driven Apps
Interface experience Custom user interface. Not limiting. Data-driven interface. Limiting unless you heavily program and update the application.
Data sources You can use just about any data source, including Dataverse. Dataverse exclusively.
Design constraints A blank canvas with unlimited interface customization options when using controls properly. The app will not need to appear as a Microsoft-based app. It is based on a predefined set of templates with limited customization. Customizing the templates requires advanced programming skills. The user experience is consistent with most Microsoft apps.
Page and design flexibility Each screen (page) can have its own look and feel. Each screen follows standard design conventions, with limited options to update the configuration.
Cost to implement It can be costly and time-consuming, depending on the complexity of the design and the level of customization among the controls used. It can be faster and more affordable to develop so long as the user interface customization is limited and the application limits the customization of the data model. This often requires more training for end users.
Accessibility and compliance The developer must address accessibility and compliance independent of app development. Microsoft handles your accessibility and responsive design requirements.

Adopting a hybrid approach

Hybrid development is most certainly a possibility. Often, users want the best features from both app types, so selecting the implementation approach isn’t always straightforward. Once you start developing, you can’t simply flip a switch and go between both development modes. You must pick the app format that accommodates your solution's needs.

If you know you’ll need both application development approaches (effectively hybrid), you should develop a model-driven application. Then you can add canvas screens to the model-driven app. A common approach is to use a model-driven app for the primary business process and then use canvas apps for specific tasks that can’t be accomplished with rigid data user experience needs.

Figure 6 shows a performance management calculator built using canvas app principles, but the application is incorporated into a model-driven app. This example accommodates a variety of user needs, all in one application.

Figure 6: A canvas-based performance review calculator inside a model driven app.

About This Article

This article is from the book: 

About the book author:

Jack Hyman is the founder and principal of IT consulting firm HyerTek, providing services to federal, state, local, and educational institutions. In that role, he helps organizations implement leading cloud platforms and analytics tools. Jack has authored several For Dummies titles, including Microsoft Power BI For Dummies.