Contents

1. Cover Page
2. Title Page
3. Copyright Page
4. Contents
5. About the author
6. Introduction​
1. Organization of this book
2. Preparing for the exam
3. Microsoft certifications
4. Quick access to online references
5. Errata, updates, & book support
6. Stay in touch
7. Chapter 1 Describe the business value of Power Platform​
1. Skill 1.1: Describe the business value of Power Platform services
2. Skill 1.2: Describe the business value of extending business solutions by
using Power Platform
3. Skill 1.3: Understand Power Platform administration and security
4. Chapter summary
5. Thought experiment
6. Thought experiment answers
8. Chapter 2 Identify the core components of Power Platform​
1. Skill 2.1: Describe Common Data Service
2. Skill 2.2: Describe connectors
3. Skill 2.3: Describe AI Builder
4. Chapter summary
5. Thought experiment
6. Thought experiment answers
9. Chapter 3 Describe the business value of Power BI​
1. Skill 3.1: Identify common Power BI components
2. Skill 3.2: Connect to and consume data
3. Skill 3.3: Build a basic dashboard using Power BI
4. Chapter summary
5. Thought experiment
6. Thought experiment answers
10. Chapter 4 Demonstrate the capabilities of Power Apps​
1. Skill 4.1: Identify common Power Apps components
2. Skill 4.2: Build a basic canvas app
3. Skill 4.3: Describe Power Apps portals
4. Skill 4.4: Build a basic model-driven app
5. Chapter summary
6. Thought experiment
7. Thought experiment answers
11. Chapter 5 Demonstrate the capabilities of Power Automate​
1. Skill 5.1: Identify common Power Automate components
2. Skill 5.2: Build a basic flow
3. Chapter summary
4. Thought experiment
5. Thought experiment answers
12. Chapter 6 Demonstrate the capabilities of Power Virtual Agents​
1. Skill 6.1: Describe Power Virtual Agents capabilities
2. Skill 6.2: Build and publish a basic chatbot
3. Chapter summary
4. Thought experiment
5. Thought experiment answers
13. Index
14. Code Snippets
1. i
2. ii
3. iii
4. iv
5. v
6. vi
7. vii
8. viii
9. ix
10. x
11. xi
12. xii
13. 1
14. 2
15. 3
16. 4
17. 5
18. 6
19. 7
20. 8
21. 9
22. 10
23. 11
24. 12
25. 13
26. 14
27. 15
28. 16
29. 17
30. 18
31. 19
32. 20
33. 21
34. 22
35. 23
36. 24
37. 25
 38. 26
39. 27
40. 28
41. 29
42. 30
43. 31
44. 32
45. 33
46. 34
47. 35
48. 36
49. 37
50. 38
51. 39
52. 40
53. 41
54. 42
55. 43
56. 44
57. 45
58. 46
59. 47
60. 48
61. 49
62. 50
63. 51
64. 52
65. 53
66. 54
67. 55
68. 56
69. 57
70. 58
71. 59
72. 60
73. 61
74. 62
75. 63
76. 64
77. 65
78. 66
79. 67
80. 68
81. 69
82. 70
83. 71
84. 72
85. 73
86. 74
87. 75
88. 76
89. 77
90. 78
91. 79
92. 80
93. 81
94. 82
95. 83
96. 84
97. 85
98. 86
99. 87
100. 88
101. 89
102. 90
103. 91
104. 92
105. 93
106. 94
107. 95
108. 96
109. 97
110. 98
111. 99
112. 100
113. 101
114. 102
115. 103
116. 104
117. 105
118. 106
119. 107
120. 108
121. 109
122. 110
123. 111
124. 112
125. 113
126. 114
127. 115
128. 116
129. 117
130. 118
131. 119
132. 120
133. 121
134. 122
135. 123
136. 124
137. 125
138. 126
139. 127
140. 128
141. 129
142. 130
143. 131
144. 132
145. 133
146. 134
147. 135
148. 136
149. 137
150. 138
151. 139
152. 140
153. 141
154. 142
155. 143
156. 144
157. 145
158. 146
159. 147
160. 148
161. 149
162. 150
163. 151
164. 152
165. 153
166. 154
167. 155
168. 156
169. 157
170. 158
171. 159
172. 160
173. 161
174. 162
175. 163
176. 164
177. 165
178. 166
179. 167
180. 168
181. 169
182. 170
183. 171
184. 172
185. 173
186. 174
187. 175
188. 176
189. 177
190. 178
191. 179
192. 180
193. 181
194. 182
195. 183
196. 184
197. 185
198. 186
199. 187
200. 188
201. 189
202. 190
203. 191
204. 192
205. 193
206. 194
207. 195
208. 196
209. 197
210. 198
211. 199
212. 200
213. 201
214. 202
215. 203
216. 204
217. 205
218. 206
219. 207
220. 208
221. 209
222. 210
223. 211
224. 212
225. 213
226. 214
227. 215
228. 216
229. 217
230. 218
231. 219
232. 220
233. 221
234. 222
235. 223
236. 224
237. 225
238. 226
239. 227
240. 228
241. 229
242. 230
243. 231
244. 232
245. 233
246. 234
247. 235
248. 236
249. 237
250. 238
251. 239
252. 240
253. 241
254. 242
255. 243
256. 244
257. 245
258. 246
259. 247
260. 248
261. 249
262. 250
263. 251
264. 252
265. 253
266. 254
267. 255
268. 256
269. 257
270. 258
271. 259
272. 260
Exam Ref PL-900 Microsoft
Power Platform
Fundamentals
Craig Zacker
Exam Ref PL-900 Microsoft Power Platform
Fundamentals

Published with the authorization of

Microsoft Corporation by:

Pearson Education, Inc. Hoboken, NJ

Copyright © 2021 by Pearson

Education, Inc.

All rights reserved. This publication is

protected by copyright, and
permission must be obtained from the
publisher prior to any prohibited
reproduction, storage in a retrieval
system, or transmission in any form
or by any means, electronic,
mechanical, photocopying, recording,
or likewise. For information regarding
permissions, request forms, and the
appropriate contacts within the
Pearson Education Global Rights &
Permissions Department, please visit
www.pearson.com/permissions
(http://www.pearson.com/permissions). No

patent liability is assumed with

respect to the use of the information
contained herein. Although every
precaution has been taken in the
preparation of this book, the
publisher and author assume no
responsibility for errors or omissions.
Nor is any liability assumed for
damages resulting from the use of the
information contained herein.

ISBN-13: 978-0-13-678876-8

ISBN-10: 0-13-678876-9

Library of Congress Control Number:

2020946246

ScoutAutomatedPrintCode

TRADEMARKS

Microsoft and the trademarks listed at

http://www.microsoft.com on the
“Trademarks” webpage are
trademarks of the Microsoft group of
companies. All other marks are
property of their respective owners.

WARNING AND DISCLAIMER

Every effort has been made to make

this book as complete and as accurate
as possible, but no warranty or fitness
is implied. The information provided
is on an “as is” basis. The author, the
publisher, and Microsoft Corporation
shall have neither liability nor
responsibility to any person or entity
with respect to any loss or damages
arising from the information
contained in this book.

SPECIAL SALES

For information about buying this

title in bulk quantities, or for special
sales opportunities (which may
include electronic versions; custom
cover designs; and content particular
to your business, training goals,
marketing focus, or branding
interests), please contact our
corporate sales department at
[email protected] or (800)
382-3419.

For government sales inquiries, please

contact
[email protected].

For questions about sales outside the

U.S., please contact
[email protected].

CREDITS

EDITOR-IN-CHIEF

Brett Bartow

EXECUTIVE EDITOR
Loretta Yates

ASSISTANT SPONSORING EDITOR

Charvi Arora

DEVELOPMENT EDITOR

Songlin Qiu

MANAGING EDITOR

Sandra Schroeder

SENIOR PROJECT EDITOR

Tracey Croom

COPY EDITOR

Liz Welch

INDEXER

Timothy Wright

PROOFREADER

Abigail Manheim

TECHNICAL EDITOR

Boyd Nolan

EDITORIAL ASSISTANT

Cindy Teeters

COVER DESIGNER

Twist Creative, Seattle

COMPOSITION

codeMantra
Contents

Introduction

Organization of this book

Preparing for the exam

Microsoft certifications

Quick access to online references

Errata, updates, & book support

Stay in touch

Chapter 1 Describe the business

value of Power Platform

Skill 1.1: Describe the business value

of Power Platform services

Analyze data using Power BI

Act with Power Apps

Build solutions that use Common

Data Service

Create flows by using Power Automate

Use connectors to access services and

data

Create powerful chatbots by using a

guided, no-code graphical interface

Skill 1.2: Describe the business value

of extending business solutions by
using Power Platform

Describe how Dynamics 365 apps can

accelerate delivery of Power Platform
business solutions

Describe how Power Platform

business solutions can be used by
Microsoft 365 apps, including
Microsoft Teams
Describe how Power Platform
business solutions can consume
Microsoft 365 services

Describe how Power Platform

business solutions can consume
Microsoft Azure services

Describe how Power Platform

business solutions can consume third-
party apps and services

Skill 1.3: Understand Power Platform

administration and security

Describe how Power Platform

implements security, including
awareness of Common Data Service
security roles and Azure Identity
Services

Describe how to manage apps and

users

Describe environments

Describe where to perform specific

administrative tasks, including Power
Platform admin center and Microsoft
365 admin center

Describe data loss prevention (DLP)

policies

Describe how the platform supports

privacy and accessibility guidelines

Chapter summary

Thought experiment

Thought experiment answers

Chapter 2 Identify the core

components of Power Platform

Skill 2.1: Describe Common Data

Service

Describe the Power Apps user

experience
Describe entities, fields, and
relationships

Describe use cases for solutions

Describe use cases and limitations of

business rules

Describe the Common Data Model

(CDM)

Describe how to use common

standard entities to describe people,
places, and things

Skill 2.2: Describe connectors

Describe triggers including trigger

types and where triggers are used

Describe actions

Describe licensing options for

connectors including standard or
premium tier

Identify use cases for custom

connectors

Skill 2.3: Describe AI Builder

Identify the business value of AI

Builder

Describe models including business

card reader, detection model, form
processing model, and prediction
model

Describe how Power Apps and Power

Automate can consume AI Builder
data

Chapter summary

Thought experiment

Thought experiment answers

Chapter 3 Describe the business

value of Power BI
Skill 3.1: Identify common Power BI
components

Identify and describe uses for

visualization controls including pie,
bar, donut, and scatter plots and KPIs

Describe types of filters

Describe the Power BI Desktop

Reports, Data, and Model tabs

Describe uses for custom visuals

including charts or controls

Compare and contrast dashboards

and workspaces

Compare and contrast Power BI

Desktop and Power BI service

Skill 3.2: Connect to and consume

data

Combine multiple data sources

Clean and transform data

Describe and implement aggregate

functions

Identify available types of data

sources including Microsoft Excel

Describe use cases for shared data

sets and template apps and how to
consume each

Skill 3.3: Build a basic dashboard

using Power BI

Design a Power BI dashboard

Design data layout and mapping

Publish and share reports and

dashboards

Chapter summary

Thought experiment
Thought experiment answers

Chapter 4 Demonstrate the

capabilities of Power Apps

Skill 4.1: Identify common Power

Apps components

Describe the differences between

canvas apps and model-driven apps

Describe portal apps

Identify and describe types of reusable

components including canvas
component libraries and Power Apps
Component Framework (PCF)
components

Describe use cases for formulas

Skill 4.2: Build a basic canvas app

Describe types of data sources

Connect to data by using connectors

Combine multiple data sources

Use controls to design the user

experience

Describe the customer journey

Publish and share an app

Skill 4.3: Describe Power Apps portals

Create a portal by using a template

Describe common portal

customizations

Identify differences in portal behavior

based on whether a user is
authenticated

Apply a theme to a portal

Skill 4.4: Build a basic model-driven

app
Add entities to app navigation

Modify forms and views

Publish and share an app

Chapter summary

Thought experiment

Thought experiment answers

Chapter 5 Demonstrate the

capabilities of Power Automate

Skill 5.1: Identify common Power

Automate components

Identify flow types

Describe use cases for and available

templates

Describe how Power Automate uses

connectors

Describe loops and conditions

including switch, do until, and apply
to each

Describe expressions

Describe approvals

Skill 5.2: Build a basic flow

Create a flow by using the button,

automated, or scheduled flow
template

Modify a flow

Use flow controls to perform data

operations

Run a flow

Chapter summary

Thought experiment

Thought experiment answers

Chapter 6 Demonstrate the
capabilities of Power Virtual
Agents

Skill 6.1: Describe Power Virtual

Agents capabilities

Describe use cases for Power Virtual

Agents

Describe where you can publish

chatbots

Describe topics, entities, and actions

Skill 6.2: Build and publish a basic

chatbot

Create a chatbot

Create a topic

Call an action

Test a chatbot

Publish a chatbot

Monitor chatbot usage

Monitor chatbot performance

Chapter summary

Thought experiment

Thought experiment answers

Index
About the author

CRAIG ZACKER is the author or

coauthor of dozens of books, manuals,
articles, and websites on computer
and networking topics. He has also
been an English professor, a technical
and copy editor, a network
administrator, a webmaster, a
corporate trainer, a technical support
engineer, a minicomputer operator, a
literature and philosophy student, a
library clerk, a photographic
darkroom technician, a shipping
clerk, and a newspaper boy.
Introduction

The Microsoft Certified: Power

Platform Fundamentals certification
is the initial entry point into a
hierarchy of Microsoft Power
Platform certifications. The PL-900:
Microsoft Power Platform
Fundamentals exam tests the
candidate’s knowledge of the
components and capabilities of the
four Microsoft Power Platform
products: Power BI, Power Apps,
Power Automate, and Power Virtual
Agents, without delving deeply into
specific programming and
administration procedures.

With the Power Platform

Fundamentals certification in place,
candidates can then move on to the
Microsoft Certified: Power Platform
App Maker Associate certification
(Exam PL-100: Microsoft Power
Platform App Maker) and the
Microsoft Certified: Data Analyst
Associate certification (Exam DA-100:
Analyzing Data with Microsoft Power
BI). These two are specialist
certifications covering more advanced
areas of the Power Apps and Power BI
products, respectively.

This book covers all the skills

measured by the PL-900 exam, with
each of the main areas covered in a
separate chapter. Each chapter is
broken down into individual skill
sections, which cover all the suggested
topics for each skill. It is
recommended that you access trial
versions of the Power Platform tools
as you work your way through this
book. Nothing can replace actual
hands-on experience, and Microsoft
provides fully functional evaluation
platforms of Power Platform tools, all
the components of which are
accessible in the cloud and require no
hardware other than a computer with
internet access. Microsoft also
provides a wealth of documentation
for all the Power Platform tools at
docs.microsoft.com
(http://docs.microsoft.com). With these

tools, as well as some time and

dedication, you can prepare yourself
for the PL-900 exam and the first step
toward your certification path.

ORGANIZATION OF THIS BOOK

This book is organized by the “Skills

measured” list published for the
exam. The “Skills measured” list is
available for each exam on the
Microsoft Learn website:
http://microsoft.com/learn
(http://microsoft.com/learn). Each chapter

in this book corresponds to a major

topic area in the list, and the technical
tasks in each topic area determine a
chapter’s organization. If an exam
covers six major topic areas, for
example, as this one does, the book
will contain six chapters.

PREPARING FOR THE EXAM

Microsoft certification exams are a

great way to build your resume and let
the world know about your level of
expertise. Certification exams validate
your on-the-job experience and
product knowledge. Although there is
no substitute for on-the-job
experience, preparation through study
and hands-on practice can help you
prepare for the exam. This book is not
designed to teach you new skills.

We recommend that you augment

your exam preparation plan by using a
combination of available study
materials and courses. For example,
you might use the Exam Ref and
another study guide for your ”at
home” preparation and take a
Microsoft Official Curriculum course
for the classroom experience. Choose
the combination that you think works
best for you. Learn more about
available classroom training and find
free online courses and live events at
http://microsoft.com/learn
(http://microsoft.com/learn). Microsoft

Official Practice Tests are available for

many exams at
http://aka.ms/practicetests
(http://aka.ms/practicetests).

Note that this Exam Ref is based on

publicly available information about
the exam and the author’s experience.
To safeguard the integrity of the
exam, authors do not have access to
the live exam.

MICROSOFT CERTIFICATIONS

Microsoft certifications distinguish

you by proving your command of a
broad set of skills and experience with
current Microsoft products and
technologies. The exams and
corresponding certifications are
developed to validate your mastery of
critical competencies as you design
and develop, or implement and
support, solutions with Microsoft
products and technologies both on-
premises and in the cloud.
Certification brings a variety of
benefits to the individual and to
employers and organizations.

More Info All Microsoft Certifications

For information about

Microsoft certifications,
including a full list of available
certifications, go to
http://www.microsoft.com/le
arn
(http://www.microsoft.com/learn).
Check back often to see what is new!

QUICK ACCESS TO ONLINE

REFERENCES

Throughout this book are addresses to

webpages that the author has
recommended you visit for more
information. Some of these links can
be very long and painstaking to type,
so we’ve shortened them for you to
make them easier to visit. We’ve also
compiled them into a single list that
readers of the print edition can refer
to while they read.

Download the list at

MicrosoftPressStore.com/ExamRefP
L900/downloads
(http://MicrosoftPressStore.com/ExamRefPL90

0/downloads)

The URLs are organized by chapter

and heading. Every time you come
across a URL in the book, find the
hyperlink in the list to go directly to
the webpage.

ERRATA, UPDATES, & BOOK

SUPPORT

We’ve made every effort to ensure the

accuracy of this book and its
companion content. You can access
updates to this book—in the form of a
list of submitted errata and their
related corrections—at:

MicrosoftPressStore.com/ExamRefP
L900/errata
(http://MicrosoftPressStore.com/ExamRefPL90

0/errata)

If you discover an error that is not

already listed, please submit it to us at
the same page.

For additional book support and

information, please visit
https://MicrosoftPressStore.com/Su
pport.
Please note that product support for
Microsoft software and hardware is
not offered through the previous
addresses. For help with Microsoft
software or hardware, go to
http://support.microsoft.com
(http://support.microsoft.com).

STAY IN TOUCH

Let’s keep the conversation going!

We’re on Twitter:
http://twitter.com/MicrosoftPress
(http://twitter.com/MicrosoftPress).
Chapter 1

Describe the business

value of Power Platform
The Microsoft Power Platform is a
collection of tools that are designed to
simplify the process of gathering,
processing, and reporting company
data. Although the Power Platform
tools are suitable for professional
development efforts—and Microsoft
uses them to build their own
Dynamics 365 and Office 365
extensibility functions—they require
little or no coding and are intended
for use by people with no formal
software development training or
experience, whom Microsoft refers to
as citizen developers.

The main Power Platform tools, as

shown in Figure 1-1, are designed to
provide users with the ability to
perform three key actions on their
data: analyze, act, and automate. The
tools that perform these actions are as
follows:

FIGURE 1-1 Microsoft Power

Platform components

■ Power BI (Business Intelligence)—With this data analytics service,

users can discover and gather data from local and cloud sources and then
visualize and share that data.

■ Power Apps—This development platform allows users to act on their

data by creating web and mobile applications without writing code.

■ Power Automate (formerly Microsoft Flow)—Users can use this

automation service to trigger complex processes and workflows.

■ Power Virtual Agents—Users can create chatbots using a graphical

interface with no coding.

In addition to these components,

Power Platform includes the following
underlying services that work together
with all the tools:

■ Common Data Service—A cloud-based service that stores and secures

data within a set of units called entities, for use in any of the Power
Platform services and Dynamics 365 applications.

■ Common Data Model—A storage schema that defines standardized

entities, attributes, and relationships that enable multiple apps to utilize
the same data.

■ Data connectors—Proxy wrappers that enable the Power Platform

tools to interact with other services. Over 200 public connectors are
available, and users can also define custom connectors.

■ AI Builder—A turnkey solution that allows users to enhance their

Power Platform apps and flows by integrating AI functions, such as object
detection, text classification, and form processing.

Need More Review? Power Platform Fundamentals

For more information on the

Power Platform components,
see
https://docs.microsoft.com/en
-us/learn/paths/power-plat-
fundamentals.

Skills covered in this chapter:

■ 1.1: Describe the business value of Power Platform services

■ 1.2: Describe the business value of extending business solutions by

using Power Platform

■ 1.3: Understand Power Platform administration and security

SKILL 1.1: DESCRIBE THE

BUSINESS VALUE OF POWER
PLATFORM SERVICES

The Microsoft Power Platform

elements allow businesses to work
with their data in more efficient ways,
by analyzing and displaying it with
Power BI, modifying and processing it
with Power Apps, and automating its
collection with Power Automate.

This skill covers how to:

■ Analyze data by using Power BI

■ Act with Power Apps

■ Build solutions that use Common Data Service

■ Create flows by using Power Automate

■ Use connectors to access services and data

■ Create powerful chatbots by using a guided, no-code graphical

interface

Analyze data using Power BI

Businesses are frequently inundated

with data from many sources and in
many formats, often more than users
can easily access, interpret, and
assimilate. Data in its raw form—
basically tables or lists of numbers—
can be difficult for large groups to
understand and use effectively. This is
why it has long been a common
practice for businesses to convert
numerical data into charts and
graphs. Users can see at a glance the
relationships between values in a
chart that would be much more
obscure in numerical form.

An individual user can easily

transform the data in a Microsoft
Excel spreadsheet into a chart and
share it with other users, but when the
data changes, the spreadsheet and
chart must be updated and
redistributed. In addition, today’s
business environments also frequently
store large amounts of data in a
variety of locations and media
formats, not just spreadsheets
maintained by a single user.

Power BI is a tool that can access data

from multiple sources, transform it
into a variety of graphical formats,
and publish the results in a cloud-
based service that users can access
from any location, using virtually any
device.

Power BI allows users to access and

view their data in ways that are more
intuitive and convenient than
traditional tables and lists of
numbers. Graphs and charts can
provide an immediate impression of
the data’s current values, as opposed
to a detailed examination of the
numbers that can take much more
time and expertise to interpret. In
addition, the Power BI user interface
can allow users to interact with their
data, such as by displaying additional
information when they click a data
point.
Power BI is a tool that consists of
services, applications, and connectors
that can access data from multiple
sources and display it in various ways.
Power BI does not manipulate or
modify the data in any way. Whether a
user is a designer using Power BI
Desktop to model data or a consumer
using the Power BI reading view to
display the published data, nothing
that either type of user does can
possibly modify or delete the
underlying data itself.

Power BI consists of two main

components:

■ Power BI service—A cloud service that provides Power BI’s consumer

functions by allowing users to access the content that designers have
created

■ Power BI Desktop—A Windows application that designers use to

gather data; transform that data by creating dashboards, reports, and
apps; and publish it to the Power BI service

Consuming Power BI Content

The object of Power BI is to

consolidate data from multiple
sources and present it in a more
visually compelling manner, using
graphical elements such as charts and
graphs. The Power BI service is the
consumer end of the tool, which runs
in the cloud and allows users to access
the data published by designers.
Power BI visuals are accessible from
the cloud using any web browser or a
mobile device, as shown in Figure 1-2.

FIGURE 1-2 Visuals published in the

Power BI service displayed in
browsers and mobile devices

After a designer connects to a data

source, creates Power BI content, and
publishes it to the service, the
connection to the source remains in
place and the published data is
updated automatically as the source
data changes. Users can thus track
information on a continual basis.

As with many of Microsoft’s cloud-

based interfaces, the Power BI service
displays are composed of multiple
tiles. The Power BI home page, shown
in Figure 1-3, contains tiles
representing the user’s favorites and
recently accessed elements by default,
as well as a navigation menu on the
left.

FIGURE 1-3 The Power BI home

page

Using combinations of tiles, the Power

BI service can display data in three
basic formats: dashboards, reports,
and apps, as described in the
following sections.

Using Dashboards

The most basic type of display in the

Power BI interface is the dashboard.
A dashboard (sometimes called a
canvas) is a one-page view, as shown
in Figure 1-4, containing tiles drawn
from one or more reports that tells a
single story.

FIGURE 1-4 A Power BI dashboard

displaying basic human resources
information for a firm

After a dashboard is published in the

Power BI service, consumers can
interact with it in a variety of ways.
For example, clicking a tile opens the
report from which the tile was taken.
Hovering the cursor over an element
of a graph, as shown in Figure 1-5,
displays the actual data value
represented.

FIGURE 1-5 A bar graph from a

Power BI dashboard with the value of
a single data point displayed

Using Reports

A report is typically a multipage

document that provides a more
complete picture of a particular
subject. By default, when a user opens
a report in the Power BI interface, the
main navigation pane collapses and a
Pages pane appears, containing a list
of the pages in the report, as shown in
Figure 1-6. When you click a tile in a
dashboard, the associated report
opens to the page containing that tile.

FIGURE 1-6 A Power BI report

containing four pages of human
resources information for a firm

Reports can contain a great deal of

information, so Power BI has controls
that can refine the displays that
appear. For example, using the Filters
pane on the right allows users to
configure the display to contain only
data conforming to specified
categories, such as dates and
locations. Designers can incorporate
bookmarks into reports that provide
alternative views of the same data
sets. Consumers can create their own
bookmarks also.

Using Apps

In Power BI, an app is a collection of

dashboards and/or reports that
designers can package as a single
content element for distribution to
consumers, as shown in Figure 1-7.
The advantage of app packaging for
consumers is that by installing a
single app, users can gain access to
many dashboards and reports at once,
all of which are available in one place.

FIGURE 1-7 A Power BI app

containing multiple reports

Note Using Apps

The use of apps with Power BI

requires a Power BI Pro
license. The basic (free) Power
BI license provides users with
limited consumer capabilities.
The (subscription-based)
Power BI Pro license, in
addition to supporting apps,
provides additional
capabilities, such as allowing
users to share dashboards and
subscribe to dashboards and
reports. The Power BI
 Premium license is intended
for large organizations and
provides dedicated service
capacity and huge amounts of
storage. As of this writing, the
Power BI Pro license is US
$9.99 per month and the
Power BI Premium license is
US $4,995 per month.

Interacting with Power BI Content

The basic data sharing paradigm of

Power BI is for designers to create
content and publish it to the Power BI
service to share it with consumers.
Designers can share content in a
variety of ways, including the
following:

■ Publishing—Designers can publish reports and dashboards to the

Power BI service and email links to consumers. When the consumer
clicks the link and installs the content, it appears in the Shared With Me
page in the Power BI interface.

■ Building apps—Designers can package multiple reports and

dashboards into an app and share it with consumers by installing the app
in their workspaces, by sending them an installation link, or by posting
the app on a website.

■ Exporting—Designers and consumers can share Power BI content by

printing from a report or dashboard and by exporting data to an Excel or
CSV file or an entire report to a PowerPoint or PDF file. Consumers can
also store Power BI content on OneDrive for Business.

Note Power BI Designers and Consumers

One of the innovative aspects

of Power BI is that users can
easily function as both
designers and consumers.
Creating dashboards, reports,
and apps does not require
coding or extensive training,
so the process of creating and
publishing content is not
limited to specialist designers
or programmers.

After consumers have access to

published Power BI content, they can
interact with it in a variety of ways.
For example, consumers can
subscribe to dashboards and report
pages using the interface shown in
Figure 1-8, which causes Power BI to
send a snapshot of the content to their
mailboxes.

FIGURE 1-8 Power BI subscription

interface

Consumers can also create alerts,

using the interface shown in Figure 1-
9, which cause Power BI to send an
email when the value for a selected
data point reaches a specified
threshold.

FIGURE 1-9 Power BI alert interface

Consumers can also exchange
thoughts with colleagues by leaving
comments in a dashboard or report,
using the interface shown in Figure 1-
10. The comments become part of the
element, and other users can read and
respond to them.

FIGURE 1-10 Power BI comment

interface

Using the Power BI Desktop

Power BI Desktop is a free Windows

application that designers use to
create Power BI content, which will be
published on the Power BI Service for
consumers to use. With an interface
similar to that of a Microsoft Office
application, as shown in Figure 1-11,
the application allows designers to
create and publish data visualizations
by completing tasks such as the
following:

FIGURE 1-11 The Power BI Desktop

interface

■ Connect to data—Power BI Desktop provides access to more than 200

data sources, as shown in Figure 1-12, which allow designers to obtain
data from the local computer; network services, such as SQL databases;
and cloud-based services, such as SharePoint and Google Analytics.
FIGURE 1-12 The Get Data dialog
box in Power BI Desktop

■ Transform and clean data—Power BI Desktop allows designers to

model their data by combining sources, removing unneeded columns,
and changing data types, using the Power Query Editor shown in Figure
1-13.

FIGURE 1-13 The Power Query Editor in Power BI Desktop

■ Create a report—With Power BI Desktop, designers can create reports

with multiple pages or single-page dashboards.

■ Add visuals—Dragging fields onto the report canvas creates

visualizations using an appropriate format for the data type. Designers
can then modify the visualization by changing the type and configuring its
properties.

■ Publish report to the Power BI service—After the report is completed,

designers can publish it to their Power BI services by selecting a specific
location using the Publish to Power BI dialog box, as shown in Figure 1-
14.

FIGURE 1-14 The Publish to Power BI dialog box in Power BI Desktop

Need More Review? Power BI Introduction

For more information on the

basics of Power BI, see
https://docs.microsoft.com/en
-
us/learn/modules/introductio
 n-power-bi.

Act with Power Apps

Power Apps is a collection of apps and

services that work with data
connectors and data sources to
provide a development environment
that allows Power Platform users to
create their own custom business apps
without requiring any coding skills.
The data used by the apps can be
stored in the Common Data Service
that is part of the Power Platform
product or in any of the more than
200 external data sources supported
by the connectors included in Power
Platform.

Power Apps allows businesses to

automate processes that would
otherwise be performed on paper. For
example, instead of carrying
clipboards into the field to document
new information or share existing
content with colleagues and clients,
people can use a tablet or smartphone
to record data and save it directly to a
database or to display live data from a
company source. Apps created with
Power Apps can run on any web
browser or almost any mobile device
using a Power Apps app for Android
or iOS.

While Power Apps is designed to be a

simplified application development
environment, it also provides an
extensible platform that professional
developers can use to create more
elaborate code-based apps.

Power Apps supports the creation of

three types of apps, as follows:

■ Canvas—Apps using a development paradigm in which users start

with a blank canvas, drag and drop visual elements onto it, and
manipulate data using functions like those in Excel. Canvas apps provide
developers with complete freedom over the design of the interface.

■ Model-driven—Apps based on an existing model with a metadata-

based architecture, which users customize by connecting to their own
data sources and by selecting and configuring components, as shown in
 Figure 1-15. After the designer selects and models the data, Power Apps
generates a user interface that is appropriate for the content.

FIGURE 1-15 App Designer in Power Apps

■ Portal—Apps realized as external facing websites created using

selected pages, layouts, and content, which allow users outside of the
organization to authenticate and then browse and view company data.
Developers can save website projects as templates, which they can use to
create new sites.

As an example, the configuration page

for the sample Cost Estimator app
shown in Figure 1-16 allows the
designer to select any element in the
app (in the left pane) and configure its
appearance (in the right pane). The
designer can also select the data
source for the information displayed
on the app page.

FIGURE 1-16 Sample app in the

Power Apps design interface

An app can have multiple pages, each

of which the designer can configure
separately. In this example, shown in
Figure 1-17, the app is designed for
display on a smartphone-sized screen,
but other form factors are available.
FIGURE 1-17 A Power Apps sample
app

Need More Review? Power Apps Introduction

For more information on the

basics of Power Apps, see
https://docs.microsoft.com/en
-
us/learn/modules/introductio
n-power-apps.

Build solutions that use Common Data

Service

As noted earlier, Power Platform

tools, such as Power BI and Power
Apps, can access hundreds of different
data sources using the connectors
supplied with the product, including
local sources, such as Excel
workbooks; network sources, such as
database servers; and cloud-based
sources, such as Microsoft SharePoint
Online. After a user establishes a
connection to one of these data
sources, the connection remains in
force as long as the source remains
available.

The Common Data Service, as the

name implies, is an underlying data
storage solution included in Power
Platform and hosted in the cloud by
Microsoft Azure, which can function
as an alternative to these outside
sources by furnishing data to any of
the Power Platform tools, as shown in
Figure 1-18. The Common Data
Service is also the default data store
for Dynamics 365 applications, such
as Dynamics 365 Sales and Dynamics
365 Customer Service.

FIGURE 1-18 Underlying services to

the Power Platform tools

The Common Data Service stores data

using entities, which are schemas
designed to contain specific types of
data. Entities consist of attributes,
which contain specific types of data
values. The Common Data Service
includes a large collection of standard
entities for frequently used data types,
a few of which are shown in Figure 1-
19.

FIGURE 1-19 Partial listing of

entities in the Common Data Service

The entities provided in the Common

Data Service are based on an open
standard called the Common Data
Model that Microsoft has published as
part of its Open Data Initiative,
developed in partnership with Adobe
and SAP. The model consists of
predefined entities, such as
application/app, business unit,
environment, region, solution, tenant,
and user, each of which have
attributes, relationships, and
metadata. Designers can also create
custom entities that are specific to the
data types required by a particular
organization.

It is common for users of Power

Platform tools to access data from
multiple sources and consolidate the
data into a single report, app, or flow.
As an alternative to maintaining
multiple data source connections, it is
possible to integrate the data from the
sources into Common Data Service,
which can then function as a single
storehouse for all the necessary local,
network, or cloud data, as well as the
organization’s Dynamics 365 data.
Users can import data from sources as
a one-time event or configure
Common Data Service to synchronize
with the outside data sources at
scheduled intervals, ensuring that the
information in Common Data Service
is always current.

The Common Data Service also

includes a flexible, role-based security
system that administrators can use to
authorize users with any degree of
access they require, down to specific
records and fields.

Create flows by using Power Automate

Power Automate is a tool designed to

automate processes involving multiple
applications that users must
otherwise complete manually.
Formerly called Microsoft Flow,
Power Automate works by creating
sequences of events called flows. A
flow typically consists of an event (or
trigger) that causes the flow
processing to begin and one or more
actions that the flow performs as a
result of the event.
The primary advantage of Power
Automate is that a flow’s events and
actions can involve different
applications or services. For example,
a user can create a flow that causes
Power Automate to send a text
message to the user’s smartphone
when the user receives an email from
a specific person.

Many applications include

automation capabilities within their
own functions, but they typically
cannot automate an action between
two or more applications. Power
Automate supports hundreds of
connectors, triggers, and actions for
different applications and services,
allowing it to perform complex action
sequences that would normally
require manual execution. Multistep
flows can incorporate actions for
different applications, as shown in
Figure 1-20.

FIGURE 1-20 Events and actions of

a multistep flow

The Power Automate portal includes a

large selection of flow templates, as
shown in Figure 1-21, which execute
common tasks or that can serve as the
starting point for customized flows.
FIGURE 1-21 Flow templates in the
Power Automate portal

Power Automate supports various

types of flows, which you can create
from the Power Automate portal or its
mobile app, as shown in Figure 1-22.

FIGURE 1-22 Creating blank rows in

the Power Automate portal

The various flow types supported by

Power Automate include the
following:

■ Automated flows—Perform specific actions without prompting when

they are triggered by an event in a specific Microsoft application, such as
Outlook, SharePoint, Teams, Dynamics 365, or OneDrive; a third-party
application, such as Adobe Creative Cloud; or a social media application,
such as Twitter

■ Instant flows (also called button flows)—Perform specific actions

when they are triggered manually by a user clicking a button or other
control in the Power Automate portal or the Power Automate mobile app,
as shown in Figure 1-23

FIGURE 1-23 Buttons in the Power

Automate mobile app
 ■ Scheduled flows—Perform specific actions at a specified date and time
or on a recurring schedule, as configured using an interface like that
shown in Figure 1-24

FIGURE 1-24 Recurrence trigger

interface for a scheduled flow

■ Business process flows—Lead users through a prescribed process to

complete a task, that consists of multiple stages, each of which has
multiple steps, as shown in Figure 1-25

FIGURE 1-25 Stages and steps of a

business process flow

■ UI flows (currently in previews)—Provide robotic process automation

(RPA) for repetitive tasks requiring mouse clicks and keyboard input,
both for applications with API support and for legacy applications
without APIs

Power Automate is a no-code (or low-

code) tool. The interfaces for creating
flows provided in the Power Automate
portal and in the mobile app are
graphical, which means users select
input from drop-down lists or by
using text boxes. However, Power
Automate internally converts flows
into code, as shown in Figure 1-26,
and users who are so inclined can
choose to work with the code directly
instead of using the graphical
controls.
FIGURE 1-26 Code view of a Power
Automate flow

Need More Review? Power Automate Introduction

For more information on the

basics of Power Automate, see
https://docs.microsoft.com/en
-
us/learn/modules/introductio
n-power-automate.

Use connectors to access services and

data

All of the Power Platform tools

depend on outside systems for the
data they display or process. Those
outside systems can be local
applications, network servers, or
cloud-based services. Power Platform
includes hundreds of connectors,
which allow the tools to access these
outside resources. Wherever the data
is located, the user working with the
Power Platform tools must have the
permissions needed to access the
data. In some cases, connector
configuration can call for careful
management of privileges.

Power BI interoperation

Power BI accesses data on outside

systems in order to display it in a
different form. Designers of Power BI
reports, dashboards, and apps must
have the privileges needed to access
the required data sources. However,
the consumers of Power BI content
have no direct access to those data
sources. They can only view the
reports, dashboards, and apps
themselves, as well as work with them
by leaving comments. Consumers
cannot modify reports, dashboards,
and apps in other ways, such as by
modifying their appearance.

There is no way for a Power BI

designer or consumer to modify the
original data when creating Power BI
content or working with the published
content. The designer is left with the
sole responsibility of determining
what data consumers are permitted to
view. Power BI includes controls that
allow the designer to share the
content they create with selected
users, who are permitted to view the
content they create. Designers can
also create workspaces that allow
users to function as co-designers of
Power BI content.

Power Apps and Power Automate

interoperation

Power Apps and Power Automate are

both tools that work bidirectionally
with data sources, meaning that it is
possible for an app or a flow to add or
modify source data, as well as read
and display it. This complicates the
process of accessing and using data
sources.

Power Apps and Power Automate

both use connectors to access external
applications, services, and data
sources. Power Platform includes over
300 public connectors, a few of which
are shown in Figure 1-27.

FIGURE 1-27 Some of the

connectors available in Power
Automate

A connector is a proxy wrapper that

the tools use to access an API
provided by an application or service.
Most applications and cloud services
include such APIs, and the Power
Platform connectors function as
proxies—that is, intermediaries
between the outside APIs and the
internal Power Platform tools. The
connector, as a proxy, authenticates to
the outside application or service and
then provides access to Power Apps
and Power Automate (as well as to
Azure Logic Apps).

Each Power Platform connector

includes a set of triggers and actions,
which are specific operations that
designers can use in their apps and
flows. Triggers are notifications
generated by the outside application
or service, indicating that a specific
event has occurred. For example, the
creation of a new item in a specific
SharePoint site can activate a trigger
in the Power Platform connector for
SharePoint, thereby launching a
particular flow containing that trigger.
There are two types of triggers in
Power Platform connectors:

■ Polling triggers—Check with the outside application or service at

regular intervals for new data

■ Push triggers—Listen for an event to occur in an outside application

or service

Actions are specific changes made to

an outside application or service,
usually as a result of a trigger. For
example, when a trigger in a Power
Automate flow indicates that a new
item has been created in a specific
SharePoint site, the associated actions
in the flow can generate notifications
and send them to users by email or
text message. Apps and flows can
include multiple actions using
different connectors, as shown in
Figure 1-28.
FIGURE 1-28 List of connectors
used by the Request manager
approval for a selected item flow
template

Create powerful chatbots by using a

guided, no-code graphical interface

Power Virtual Agents is a recent

addition to the Power Platform toolkit
that allows citizen developers to
create customer service chatbots and
embed them into websites using a
simplified no-code interface.
Chatbots, in this instance, are
automated, text-based
communication interfaces that use
branching logic and artificial
intelligence to communicate with
online clients, ascertain their needs,
and in some cases satisfy those needs
by triggering flows that perform
specific tasks.

When a developer creates a virtual

agent and adds a default greeting, an
authoring canvas appears like the one
shown in Figure 1-29. By default, the
bot’s standard Greeting topic is
configured to respond to any one of 52
trigger phrases representing possible
initial statements by the client with a
standard greeting.

FIGURE 1-29 The Power Virtual

Agents default greeting

The trigger phrases do not have to

match the user’s input exactly. Power
Virtual Agents uses a natural
language understanding module to
match variants of the trigger phrases
with an appropriate response. The
developer can add more trigger
phrases and modify the bot’s greeting
as needed.

To extend the conversation, the

developer can create additional topics
that ask the user questions, obtain
information from the user, and take
action based on that information. For
example, Figure 1-30 shows a simple
yes or no question and the branching
logic that allows the developer to
continue the conversation in different
ways, depending on the response
given.

FIGURE 1-30 A Power Virtual

Agents topic with branching logic

Power Virtual Agents can work

together with Power Automate, so
developers can create flows that
perform tasks using information
gathered from the user and integrate
them into conversations. For example,
in the case of a user wanting to check
the status of an order, a topic in the
bot’s conversation can prompt the
user to specify an order number.
Then, the bot can pass the order
number to a flow that performs a
database lookup and supplies
information about the order back to
the bot, which displays it to the user.
For conversations that are unable to
provide what the user needs, a topic
can pass the user to a live agent.

SKILL 1.2: DESCRIBE THE

BUSINESS VALUE OF EXTENDING
BUSINESS SOLUTIONS BY USING
POWER PLATFORM

Power Platform provides a layer of

connectivity for a large number of
business environments by allowing
users to analyze their existing data,
create apps that process their data,
and automate their data gathering
and updating processes. As an
underlying collection of tools, Power
Platform can provide additional
connectivity both within and among
the various applications and services
in Dynamics 365, Microsoft 365,
Microsoft Azure, and other third-
party products, as shown in Figure 1-
31.

FIGURE 1-31 Power Platform

components and connectivity

This skill covers how to:

■ Describe how Dynamics 365 apps can accelerate delivery of Power

Platform business solutions

■ Describe how Power Platform business solutions can be used by

Microsoft 365 apps, including Microsoft Teams

■ Describe how Power Platform business solutions can consume

Microsoft 365 services

■ Describe how Power Platform business solutions can consume

Microsoft Azure services

■ Describe how Power Platform business solutions can consume

third-party apps and services

Describe how Dynamics 365 apps can

accelerate delivery of Power Platform
business solutions

Dynamics 365 is a series of business

applications that is intended to
digitally transform organizations by
utilizing the data that can be
generated by nearly every process
essential to productivity. The
traditional application model of
“forms over data” creates new data as
a result of business transactions,
whether they are customer
relationship interactions or internal
resource management exchanges. The
interaction comes first, and data is
generated as a result of workers filling
out digital forms to document the
activity.

Digital transformation is a reversal of

this process in which the data comes
first, data that is now produced by
virtually every device and business
process. Modern business devices,
applications, and services of almost
every kind are capable of generating
data during their operations and can
export it for processing. Virtually all
business tools, from environmental
devices, such as thermostats and
HVAC systems, to industrial
machinery, to customer relationship
management (CRM) and enterprise
resource management (ERP) systems,
are capable of generating a
continuous stream of data as they
operate. The Dynamics 365
applications—in cooperation with the
underlying Power Platform tools—can
then use this data to track
performance and anticipate future
incidents and conditions, thus
changing a reactive system to a
proactive one.

For example, in the past, a customer

experiencing a vital equipment failure
would have to call the manufacturer of
the equipment and request a service
call. The manufacturer’s customer
service representative would then
create a service request by filling out a
form in an application. Only at this
point did data begin to be created. The
manufacturer’s support team would
then start the process by which the
service request’s urgency was
assessed, the problem investigated,
and a service technician dispatched to
address the problem. All during this
process, the equipment was down,
and the customer was experiencing
lost productivity.

Now, after the digital transformation,

the customer’s equipment can
generate a constant stream of data
that is relayed directly to the
manufacturer. By monitoring and
processing the data, the manufacturer
can detect a potential problem before
it causes a failure and dispatch a
technician on a maintenance call.

The Dynamics 365 applications and

the Power Platform tools provide the
analytics needed to utilize this
generated data to connect all aspects
of the organization, including the
human elements—employees and
customers—and the business
elements—products and operations.
This process by which business
activities generate data and the
Dynamics 365 applications use that
data to facilitate further business
activities, as shown in Figure 1-32, is
called the digital feedback loop, in
Microsoft parlance.

FIGURE 1-32 The Dynamics 365

digital feedback loop

Dynamics 365 is a collection of

applications that all share the same
data and intelligence. Here are some
of the applications:

■ Sales—Tracks customer accounts and contacts and performs

marketing-related tasks

■ Customer Service—Manages customer relationships

■ Field Service—Provides scheduling and workflow automation for

onsite mobile field workers

■ Marketing—Works with the Sales application to create compelling

documents and emails and shares marketing and sales information with
internal product teams

■ Commerce—Provides comprehensive and unified digital, call center,

back-office, and in-store experiences

■ Finance—Provides real-time performance monitoring and uses

artificial intelligence to predict future financial performance

■ Human Resources—Provides employee recordkeeping functions and

tracks companywide statistics on employee retention, training, and
performance

■ Supply Chain Management—Manages planning, inventory, and

production and uses artificial intelligence to predict future needs

■ Business Central—Provides smaller businesses with automation of

sales, finance, manufacturing, and other business processes

Microsoft originally designed the

Common Data Service as a platform
for the Dynamics 365 applications,
which use it to store and retrieve their
data. Later, Microsoft created the
Power Platform tools to function as a
low-code/no-code extensibility
platform for Dynamics 365 by having
it use the same Common Data Service.
The data generated by the Dynamics
365 applications is available to all the
Power Platform tools, as well as to
other applications and services that
store data in the Common Data
Service.

Describe how Power Platform business

solutions can be used by Microsoft 365
apps, including Microsoft Teams

Developers can integrate the content

they create using the Power Platform
tools into various Microsoft 365
applications and services, including
Microsoft Teams. For example, to
insert a Power Apps app into Teams,
the developer must use the App ID on
the app’s Details screen to identify the
app to Teams. The App ID is a 128-bit
globally unique identifier (GUID),
notated as 32 hexadecimal digits, as
shown in Figure 1-33.
FIGURE 1-33 Details screen of an
app in the Power Apps portal

In Microsoft Teams, the developer

must first install the Apps Studio
application, then create a new Teams
app. Rather than create a new app in
Teams, the developer then identifies
the Power Apps app to be embedded
by specifying its App ID in the
Identification section of the App
Details screen, as shown in Figure 1-
34.

FIGURE 1-34 The App Details

screen in Microsoft Teams App Studio

The developer can then complete the

process of configuring the new app in
Teams App Studio and distribute it to
users in the tenancy. The app then
appears as a tile on the Add a tab
screen in Teams, enabling the
developer to add it as a tab on the
General screen for the selected users.

Describe how Power Platform business

solutions can consume Microsoft 365
services

Microsoft 365 is a suite of applications

that includes Windows 10, Office 365,
and Enterprise Mobility + Security.
Power Apps and Power Automate are
included with all of the Microsoft 365
products, but only the Microsoft 365
Enterprise E5 product includes the
Pro version of Power BI. However, all
the Power Platform tools are available
as separate products and can be
added to a Microsoft 365 deployment.

Exam Tip

The original version of Power BI

for Office 365 was an add-on
product that added visual
functionality to existing Excel
Power View reports. There was
also a Windows 8 app that allowed
users to access those reports
remotely. This version of Power BI
was deprecated as of December 31,
2015 in favor of the new service-
based version of Power BI that is
part of the Power Platform today.
When preparing for the PL-900
exam, be aware that some
outdated documentation still
exists on the internet that refers to
this original Power BI version and
not the current one.

As noted earlier, when Microsoft first

began rolling out the Power Platform
tools several years ago, they designed
them primarily as an extensibility
platform for the Dynamics 365 ERP
and CRM applications. This was an
obvious direction to take because the
Power Platform and Dynamics 365
products were all designed to use the
Common Data Service. However,
Microsoft has announced their
intention to expand that extensibility
platform to include Microsoft 365
applications and services as well.

Unlike Dynamics 365, the Microsoft

365 components are not built on the
Common Data Service, so they do not
have the same shared data connection
with the Power Platform tools.
However, the Power Platform tools
include connectors that allow them to
access and use the data generated by
the Microsoft 365 applications and
services.

For example, citizen developers at an

organization running Microsoft 365
can use Power BI to gather data from
branch sites and mobile SharePoint,
Exchange, and Teams users as they
roam around the facilities or work in
the field. They can then create
dashboards or reports to display a
conglomerated picture of the data
from those various sources. Power BI
allows the organization to monitor,
analyze, and visualize trends in sales,
supply, and other aspects of the
business, helping them to anticipate
needs before they arise.

Using Power Apps and AI Builder,

developers can create applications
that use text and image recognition to
collect additional data from users as
they work with Microsoft 365
applications and services, rather than
requiring them to enter data manually
on forms-based interfaces. For
example, mobile users can
photograph shelves in stores and
warehouses; an app can then scan the
photographs, count the number of
products on the shelves, and use the
data to update a Power BI dashboard
with up-to-the-minute information.
This additional data can then also be
stored in the Common Data Service.

With Power Automate, citizen

developers can create flows that
perform time-consuming tasks
automatically. In the previous
example, the automated shelf-
counting app can result in the
creation of orders for additional
products. When a new order arrives at
the supplier’s mailbox, a flow can read
the products requested and check the
inventory to see whether they are
available. If the products are
available, the flow can trigger a
shipment; if they are not, the flow can
branch to a different process that
classifies the products as back-
ordered and notifies the requestor.
Using the connectors supplied with
the Power Platform tools, flows can
interact with various Microsoft 365
applications and services.

Describe how Power Platform business

solutions can consume Microsoft Azure
services

Microsoft Azure is Microsoft’s cloud-

based architecture for providing
hundreds of Software as a Service
(SaaS), Platform as a Service (PaaS),
and Infrastructure as a Service (IaaS)
products to customers. The Power
Platform tools run on the Azure
backbone and are heavily reliant on it
for their cloud presence, data storage,
and other resources. The Common
Data Service stores its data in the
Azure cloud, and the portals for the
various Power Platform tools are all
Azure-based cloud services.

Because it is cloud based, Microsoft

Azure makes the Power Platform tools
available to users at any location,
using any device. Power BI, Power
Apps, Power Automate, and Power
Virtual Agents all have mobile apps
that allow users to function as both
designers and consumers using a
smartphone or tablet.

Describe how Power Platform business

solutions can consume third-party apps
and services

Aside from their compatibility with

Microsoft applications and services,
the Power Platform tools have
connectors that allow them to access
data sources from third-party
applications and services. Hundreds
of public connectors are available that
allow users to work with data from
various social media and other
commercial products. The data
sources accessed using connectors can
be combined with Common Data
Service data to create composite
representations in Power BI, Power
Apps, and Power Automate.

For applications or services with

representational state transfer (REST)
APIs that are not supported by the
public connectors included in Power
Platform, it is possible to create
custom connectors. Administrators
can create connectors using definition
files based on the OpenAPI or
Postman standard, for APIs that
support them, or they can build a
custom connector from scratch by
creating a new definition.

SKILL 1.3: UNDERSTAND POWER

PLATFORM ADMINISTRATION
AND SECURITY

As with any other application or

service, the Power Platform tools
require attention to administration
and security to configure them
properly and prevent them from being
misused.

Power Platform itself is not a single

service; the name refers to a collection
of services that organizations can use
individually or in combination. The
Power Platform tools—Power BI,
Power Apps, Power Automate, and
Power Virtual Agents, along with their
underlying components (Common
Data Service, data connectors, and AI
Builder)—run as individual services,
meaning that they are cloud-based
software products that are hosted by
Microsoft Azure on a software as a
service (SaaS) basis. Each of the four
main tools has its own portal, as
shown in Figure 1-35, in which users
can design and consume content.

FIGURE 1-35 A Power Platform tool

portal

Note Power BI Desktop

The only Power Platform

component that is not a cloud-
based service is Power BI
Desktop, which is a standalone
Windows application that
designers can use to establish
data connections; create
reports, dashboards, and
apps; and upload them to the
Power BI service in the cloud,
which makes them available to
consumers. Power BI Desktop
is not an essential component;
designers can create
dashboards, reports, and apps
in the Power BI Service portal
as well.

Because they are Azure services, the

Power Platform tools can take
advantage of many of the advantages
that Azure provides, including high
availability due to redundant data
centers, localized access using Azure
Traffic Manager (ATM), and identity
management provided by Azure
Active Directory (AAD).

This skill covers how to:

■ Describe how Power Platform implements security, including

awareness of Common Data Service security roles and Azure Identity
Services

■ Describe how to manage apps and users

■ Describe environments

■ Describe where to perform specific administrative tasks, including

 Power Platform admin center and Microsoft 365 admin center

■ Describe data loss prevention (DLP) policies

■ Describe how the platform supports privacy and accessibility

guidelines

Describe how Power Platform implements

security, including awareness of Common
Data Service security roles and Azure
Identity Services

Any development environment—even

a no-code/low-code one—is subject to
abuse by unauthorized users, whether
intentional or not. However, because
the Power Platform tools are designed
for an audience of citizen developers,
as well as content consumers, security
is a particularly important aspect of
their administration. Code-based
development environments are not
understood by most users, which
helps to protect them from casual
interference, but they are still subject
to deliberate tampering by malicious
outsiders. Therefore, the Power
Platform tools require security
mechanisms like those of any other
cloud-based service.

All of the Power Platform tools rely on

the Azure Active Directory identity
services for user accounts and
licensing. Administrators therefore
use the standard Azure tools, such as
Microsoft 365 admin center, for user
account maintenance and license
assignment. Apart from this, the main
Power Platform tools operate
independently, so they each have their
own security architecture. The
following sections examine the
security considerations for each
component.

Power BI security

At its most basic, security in Power BI

is a matter of sharing content with
other users. Developers control access
to their content by sharing
dashboards, reports, or apps with
specific consumers using the interface
shown in Figure 1-36. However, for
users to access Power BI in the first
place, they must first be authenticated
and authorized for specific content.

FIGURE 1-36 Power BI Share

Dashboard dialog box

Power BI, as implemented in

Microsoft Azure, is a service that
consists of two clusters: the Web
Front End (WFE) cluster and the
Back-End cluster, as shown in Figure
1-37.

FIGURE 1-37 Power BI clusters

architecture

The WFE cluster is responsible for the

initial connection by users to the
Power BI service and the
authentication of the user account, in
a process shown in Figure 1-38.
FIGURE 1-38 Browser interaction
with the Power BI WFE cluster
components

When a user directs a browser to

Power BI by typing a URL or clicking
a hyperlink, the following procedures
occur:

1. The Azure Traffic Manager (ATM) examines the user’s DNS record
and directs the browser connection to the WFE cluster in the nearest
Microsoft data center.

2. The WFE cluster directs the user connection to the Microsoft Online
Services login page.

3. The user is asked to authenticate against its account in Azure Active

Directory (AAD). When the authentication is successful, the login page
directs the connection back to the WFE cluster.

4. The WFE cluster authorizes the user’s Power BI service subscription

with Azure Active Directory and, if the authorization is successful,
obtains an AAD security token.

5. The WFE cluster consults the Power BI Global Service to determine

the location of the correct Back-End cluster for the tenant to which the
user belongs.

6. The WFE cluster directs the user connection to the correct Back-End
cluster and supplies the user’s browser with the AAD security token,
the address of the Back-End cluster obtained from the Global Service,
and information about the current session.

7. The user’s browser downloads the common files needed to interact

with the Power BI service from the WFE cluster and from the Azure
Content Delivery Network (CDN). The browser maintains these files
for the duration of the session with the Power BI service.

After the authentication and

authorization processes are completed
successfully by the WFE cluster and
the browser downloads the necessary
files, all subsequent Power BI
communication takes place between
the browser and the Back-End cluster
directly, without further participation
of the WFE cluster.

The Back-End cluster hosts a variety

of roles, as well as the data storage
media where the Power BI
information is stored, as shown in
Figure 1-39. The dotted line in the
figure represents the division between
the modules that are accessible to
users via the public internet (on the
left) and those that are accessible only
indirectly (on the right).

FIGURE 1-39 Power BI Back-End

cluster components

The Back-End cluster is responsible

for all the Power BI operations for
authenticated clients, including the
establishment and maintenance of
data connections, the creation of the
visualizations in dashboards and
reports, and the storage of data. Users
communicating with the Back-End
cluster do so through the Gateway
Role.

The Gateway Role and Azure API

Management are the only modules
accessible to users through the public
internet. These modules accept and
manage user connections, authorize
users for specific content, and then
relay all incoming user requests to the
other modules in the cluster as
needed. For example, a typical
transaction in which a user attempts
to access a Power BI dashboard, as
shown in Figure 1-40, proceeds as
follows:
FIGURE 1-40 Power BI transaction

1. The user’s browser accesses the Power BI portal and connects to the
WFE cluster.

2. The WFE cluster authenticates the user and authorizes the user’s
access to Power BI.

3. The browser connects to the Back-End cluster.

4. The user generates a request to display a dashboard and sends it to the

Gateway Role in the Back-End cluster.

5. The Gateway Role forwards the request to the Presentation Role,

which is responsible for supplying the data needed to create the
visualization of the dashboard in the user’s browser.

6. The Presentation Role sends the requested data to the Gateway Role.

7. The Gateway Role forwards the data to the user’s browser, and the
browser displays the requested dashboard.

Thus, the Presentation Role (and all of

the other non-public roles in the
Back-End cluster, including the Data
Role, the Background Job Processing
Role, and the Data Movement Role)
are protected from direct internet
access by users, both authorized and
unauthorized.

Note Power BI Premium

Power BI Premium is a
subscription level that
provides a tenant with a
dedicated Back-End service
cluster, as shown in Figure 1-
41, created on virtual
machines located in the same
data center as the tenant.

FIGURE 1-41 Power BI Premium

Back-End cluster architecture

The Premium cluster contains

 separate instances of roles
found in the Back-End cluster,
including the Gateway Role,
Azure API Management, Data
Role, and Job Processing Role,
as well as a separate Azure
SQL Database. All
communication with the
dedicated Premium cluster
goes through the shared Back-
End cluster, which relays
traffic to and from the
Gateway Role in the Premium
cluster.

Designers should also be conscious of

the security of the data they use to
create dashboards and reports, in
addition to the authentication needed
to access the Power BI service. When
Power BI designers connect to a data
source, they typically have to supply
credentials for a separate
authentication to that source. A
dashboard or report that contains the
data uses the designer’s credentials to
access and update that data. However,
when the designer shares the
dashboard or report with consumers,
those users are not authenticated to
the original data sources. Therefore, if
the data in the Power BI content is
sensitive, the designer is solely
responsible for making it accessible to
the consumers. As noted earlier in this
chapter, Power BI users cannot
modify the data used to create
dashboards and reports, but in
situations where the data is
confidential, designers must control
who has access to their Power BI
content.

The Back-End cluster contains two

forms of data storage: Azure Blob and
an Azure SQL Database instance.
Azure Blob is a storage solution that
Azure uses for large amounts of
unstructured data. Power BI uses
Azure Blob storage for data that
designers import from a source, such
as an Excel worksheet. Power BI uses
the Azure SQL Database for all other
data, including tenant information,
workspaces, dashboards and reports,
and metadata.

When designers access data sources,

they do so in two possible ways:

■ Import—Data accessed from a file, such as an Excel worksheet

■ DirectQuery—Data accessed using a reference to an outside source,

such as a SharePoint site or a database

The Data Role in Power BI reads

imported data into an Analysis
Services in-memory database, in
which it is retained for up to one hour,
and also stored in Azure Blob storage
in encrypted form. Data accessed by
DirectQuery is also stored in the
Analysis Services database, but only
while it is in process—that is, when a
procedure occurs that requires access
to the data, such as when a user
accesses a data set or modifies a
report or dashboard, or when a data
refresh occurs. The Analysis Services
database is unencrypted to allow
Power BI to access the necessary data
immediately. When data is at rest, the
opposite of in process, it is stored in
either in Azure Blob or the Azure SQL
Database, and is always encrypted.

Power Apps Security

As with all the Power Platform tools,

Power Apps relies on a layered
security model that includes the
following elements:

■ Azure Active Directory authentication—Power Apps uses Azure Active

Directory (Azure AD) user accounts to control access to its portal and to
specific apps. Administrators with appropriate Azure AD credentials can
assign Power Apps licenses to users and grant them access to specific
apps and security roles. Administrators can also use other Azure tools to
regulate access to Power Apps, including conditional access policies and
the mobile application protection policies provided by Microsoft Intune.

■ Power Apps licensing—Developers and consumers must possess a

Power Apps license to access the portal, create apps, and run apps.

■ Environment security roles—Each environment has two built-in

administrative security roles, as follows. To assign users to these roles,
administrators use the interface shown in Figure 1-42, found in the Power
Apps admin center.
 FIGURE 1-42 Assigning the Environment Maker role

■ Environment Admin—Can perform all administrative tasks for an

environment, including adding users to the Environment Admin and
Environment Maker roles, creating Common Data Service databases,
and managing all other resources in the environment.

■ Environment Maker—Can create resources in the environment,

including apps, flows, connections, custom connectors, and gateways,
and share apps with other users.

■ App sharing—Developers can choose to share apps with other Azure

AD users through the interface shown in Figure 1-43. By default, the
selected sharers are standard users of the app, but the developer can also
designate them as co-owners. A co-owner of an app can edit it and share
it with others but cannot delete the app or change its owner.

FIGURE 1-43 Power Apps Share

dialog box

■ Environment boundaries—An environment is a container for apps,

flows, and data that is separate from any other environments in the same
tenant. A tenancy has a single environment by default, which is named
for the tenant. Administrators can create all their apps and flows in that
default environment, or they can choose to create additional
environments in that tenant to make separate development spaces. For
example, administrators can create separate environments for the various
teams or departments in the organization, use them to separate testing
and production versions of apps, or use them to create spaces with
different security requirements. Each environment is created in a selected
geographic region, and all of the environment’s resources are bound to
that region. If an administrator chooses to create a Common Data Service
database in an environment, that database and the data it contains are
only available to apps and flows created in that same environment.

■ Connector credentials—The Share dialog box also lists the data

connections used by the app. The administrator must see to it that the
selected users also have credentials with the permissions required to
access the data sources the app needs to function. Power Apps does not
provide users with access to data for which they do not already have
permissions.

■ Common Data Service user security roles—A Common Data Service

database has three standard security roles, which are sets of permissions
that administrators can assign to users and groups and which determine
what operations the users can perform on database entities.
Administrators can also create custom security roles that contain any
combination of the following record-level privileges: create, read, write,
delete, append, append to, assign, and share.

■ System Customizer—Provides the users with the create, read,

write, and delete permissions for the entities they create and the
permission needed to customize the environment.

■ Common Data Service User—Allows the users to run apps in the

environment and provides them with the read, create, write, and
delete permissions for the records they own. All users added to the
environment receive this role by default.

■ Delegate—Allows users to impersonate other users and run code

on their behalf.

Power Automate Security

When users create a flow in Power
Automate (or an app in Power Apps),
they must supply authentication
credentials for any connector
providing access to a third-party
application or service. For example,
when creating a flow that is triggered
by the addition of an event to a Google
calendar, the designer must provide
the credentials needed to log on to the
Google account containing the
calendar to be monitored.

This fact raises a security concern that

the designer must consider. Does the
designer want users with whom the
flow or app is shared to have access to
those credentials? The answer
depends on the circumstances, and
designers sometimes have multiple
options.

When creating and sharing canvas

apps in Power Apps, designers will
find that the credentials specified for
some connectors are shared with the
users receiving the app, whereas other
connectors require the app users to
specify their own credentials to gain
access to a third-party application or
service.

In the case of flows created with

Power Automate, designers can share
flows with other users in the following
two ways:

■ Co-owners—Receive full access to all the connections configured in

the flow. Running the flow as is utilizes the existing connection
credentials. Co-owners can also modify the flow using the existing
credentials or reconfigure connections to use different credentials.
However, co-owners cannot use the shared credentials to create their own
new flows. Adding a co-owner to a flow causes Power Automate to display
a Connections Used warning like the one shown in Figure 1-44.
 FIGURE 1-44 Connections Used window in Power Automate

■ Run-only users—An option only in manually triggered flows. When

flow creators add run-only users, they must specify whether the
connections in the flow will use the credentials provided by the creator or
the run-only users must specify their own credentials, as shown in Figure
1-45.

FIGURE 1-45 Run-only user permissions

Describe how to manage apps and users

While the administration of Power BI

is relatively simple, because the tool
interacts with data sources on a read-
only basis, Power Apps and Power
Automate have the ability to modify
data sources, and administrators must
be more careful to regulate the
privileges allotted to apps and users.

Managing apps

In the Power Apps portal, the Apps

page, shown in Figure 1-46, allows
you to select an app and edit it, run it,
configure its settings, share it with
other users, export it, add it to
Microsoft Teams, or display its run
history.

FIGURE 1-46 The Apps page in the

Power Apps portal

Managing users
Because the Power Platform tools are
all based on Microsoft Azure, they do
not need their own identity
subsystems; they use Azure Active
Directory user accounts to control
access to the tool portals and to the
resources in each tool.

To create users and manage user

account properties, administrators
typically use the Microsoft 365 admin
center, as shown in Figure 1-47.

FIGURE 1-47 The Active users page

in the Microsoft 365 admin center

After creating users, the

administrator’s next step in providing
them with access to the Power
Platform tools is to assign them the
appropriate licenses, using the
interface generated by the Manage
product licenses button, as shown in
Figure 1-48.

FIGURE 1-48 The Licenses and

Apps tab for a selected user

The licenses available for assignment

depend on the product subscriptions
purchased by the tenant. The Power
Platform tools have various levels of
licensing, some of which are bundled
with other products. For example, the
Microsoft 365 and Dynamics 365
products include Power Apps and
Power Automate (which may still be
called Microsoft Flow). However, the
capabilities of those versions are
relatively limited, compared with
those of the standalone subscriptions,
which must be purchased separately.

After assigning licenses, it might then

be necessary for administrators to
assign security roles to users. Security
roles are associated with business
units and are combinations of access
levels and permissions that allow
users to access data—such as data
stored in the Common Data Service—
to a specific degree. It is typically
users who will be working with model
apps for Dynamics 365 who require
security roles.

The interface for the assignment of

security roles is found in the
Dynamics 365 user management
center, as shown in Figure 1-49. This
interface is accessible from the Power
Apps admin center on the Security tab
for a selected environment.

FIGURE 1-49 The Manage User

Roles dialog box

Exam Tip

As noted in the Power Apps admin

center, the management of
 security roles has been moved to
the Dynamics 365 user
management center. As of this
writing, Microsoft is in the process
of moving various administrative
functions between the Power
Platform admin center and the
Power Apps admin center. When a
function is moved, it is typically
replaced by a notice specifying the
new location. When studying for
the PL-900 exam, be conscious of
the possible relocation of admin
center functions.

Describe environments

When an administrator creates a

tenancy in Azure Active Directory for
any of the Power Platform tools or
other Microsoft products, the software
creates a default environment for that
tenant. This initial environment is
named for the tenant. An
environment is a container for the
apps and flows created in Power Apps
and Power Automate, as well as the
data they use. The Power Apps and
Power Automate portals both show
the current environment they are
using in the upper right of the screen,
as shown in Figure 1-50.

FIGURE 1-50 The environment

indicator in the Power Apps portal

Because environments are associated

with an Azure AD tenant, only the
users in that tenancy can access the
environment’s resources. The
environment is also bound to the
tenant’s geographical location.

Administrators can create only one

Common Data Services database in a
given environment. The data stored
within that database is accessible only
to apps and flows created in the same
environment.

However, it is also possible for

administrators to create additional
environments. The Environments
page in the Power Platform admin
center, shown in Figure 1-51, lists all
of the current tenant’s environments.

FIGURE 1-51 The Environments

page in the Power Platform admin
center

Clicking the +New button opens the

New environment dialog, as shown in
Figure 1-52, in which the
administrator specifies a name, type,
and region for the environment. A
second page contains options to
specify the default language and
currency values for the environment.
In addition, there is a Create a
database for this environment control
that causes the tool to create a
Common Data Services database
along with the environment.
FIGURE 1-52 Power Platform New
environment dialog box

There are several reasons why

administrators might want to create
multiple environments in a particular
tenancy. They can create separate
environments for the teams,
departments, or locations in an
organization, or they might use them
to separate app and flow development
or testing projects from those released
to production.

When creating an environment, an

administrator must choose one of the
following types:

■ Production—Intended for permanent use and deployment; requires a

Power Apps license and one gigabyte of storage space. The default
environment created for each Azure AD tenant is a production
environment.

■ Sandbox—Intended for nonproduction use, such as for development

and testing; includes functions to copy the contents of the environment to
another environment and reset the environment to its original state by
deleting all of its contents and re-creating it.

■ Trial—Intended for short-term testing; limited to 30 days and one

user.

■ Developer—Intended for use only by the owner, who must possess a

Community Plan license.

After an administrator has created

multiple environments in a tenant,
clicking the environment indicator in
the Power Apps and Power Automate
portals opens an Environments dialog
that functions as a selector, as shown
in Figure 1-53.

FIGURE 1-53 The Environments

selector in the Power Apps portal

Describe where to perform specific

administrative tasks, including Power
Platform admin center and Microsoft 365
admin center

Microsoft Azure services typically

have portals called admin centers that
provide access to configuration
settings, resources specific to the
service, support topics, and links to
other admin centers. For Microsoft
365 subscribers, the Microsoft 365
admin center is the primary
configuration interface, enabling
administrators to create and manage
user accounts, purchase and manage
product subscriptions, and access the
other available admin centers, as
shown in Figure 1-54.

FIGURE 1-54 The All admin centers

page in the Microsoft 365 admin
center

The All admin centers list includes the

admin centers for Power Automate,
Power Apps, and Power BI. However,
there is also an admin center for
Power Platform, which does not
appear on the list. The Power
Platform admin center provides
administrative access to the tenant’s
existing environments, as shown in
Figure 1-55, as well as the ability to
create new ones.

FIGURE 1-55 Environment Settings

page in the Power Platform admin
center

The Analytics menu provides real-

time statistics for the Power Platform
tools, and the Admin centers menu
provides links to the Power Automate,
Power Apps, and Power BI admin
centers, plus the Dynamics 365 admin
center, if the organization subscribes
to it. Microsoft is gradually migrating
other functions from the Power Apps,
Power Automate, and Dynamics 365
admin centers to the Power Platform
admin center.

Because Power Apps and Power

Automate are often used together,
with apps triggering flows as
necessary, their admin centers are
identical in functionality (as shown in
Figure 1-56), and that functionality is
limited by the movement of some
controls to other admin centers, such
as those for Power Platform and
Dynamics 365. The primary tasks
possible in these admin centers is the
management of app and flow sharing.

FIGURE 1-56 The Power Apps

admin center
The Power BI Admin portal, shown in
Figure 1-57, has a menu bar with 12
items, several of which display links to
other admin centers. For example, the
Users and Audit logs menus both link
to the Microsoft 365 admin center,
which is where you manage these
elements. Other menus provide
controls for features only available in
the Power BI Premium product or
that require the activation of other
Microsoft Azure applications.

FIGURE 1-57 The Usage metrics

page in the Power BI Admin portal

Describe data loss prevention (DLP)

policies

The Power Platform tools are

designed to access data from outside
sources and, in some cases, write data
back to those sources. Developers can
create canvas apps and flows that
access multiple data sources with
different sensitivity levels. This
process is inherently dangerous
because the Power Platform content
will eventually be deployed to
consumers, who might or might not
warrant direct access to sensitive data.
Power Platform developers and
administrators must exercise control
over access to the data sources they
use, and one method of doing so is to
create data loss prevention policies.

Data loss prevention (DLP) policies

are rules, created in the Power
Platform admin center, that allow
tenant admins and environment
admins to classify connectors in three
groups, as follows:
 ■ Non-business—Intended for connectors that access non-sensitive data.
Connectors in this group cannot share data with connectors in the
Business group. A newly created DLP rule places all connectors in this
category by default.

■ Business—Intended for connectors that access sensitive data.

Connectors in this group can share data with other connectors only in the
Business group; they cannot share data with connectors in the Non-
business group.

■ Blocked—Intended for connectors that are not to be used in the

environment at all.

To create DLP policies using the

wizard in the Power Platform admin
center, administrators assign the
policy a name and use the interface
shown in Figure 1-58 to move selected
connectors from the Non-business
group to the Business or Blocked
group.

FIGURE 1-58 The Assign connectors

page in the New Policy wizard

Then, using scope options,

administrators can apply the new DLP
policy to an entire tenancy or to
specific environments within the
tenancy.

Describe how the platform supports

privacy and accessibility guidelines

In any service or application that

stores data that is potentially
sensitive, and especially in cloud-
based applications and services, there
might be statutes and standards to
which the organization must comply,
whether because of contracted terms,
company policies, or governmental
requirements.

Microsoft is aware of these

compliance issues and has created a
central storehouse for information
about them called the Service Trust
Portal (STP). STP is a website that is
available to everyone at
servicetrust.microsoft.com
(http://servicetrust.microsoft.com), although

some parts of the site are restricted to

registered users of Microsoft 365 and
other products. Among the many
resources on the site are links to
documents in the following
categories:

■ Audit Reports—Provides independent audit and assessment reports of

Microsoft’s cloud services, evaluating their compliance with standards
such as those published by the International Organization for
Standardization (ISO), Service Organization Controls (SOC), National
Institute of Standards and Technology (NIST), Federal Risk and
Authorization Management Program (FedRAMP), and General Data
Protection Regulation (GDPR)

■ Documents & Resources—Consists of a large library of documents,

including white papers, FAQs, compliance guides, penetration test
reports, Azure security and compliance blueprints, and other data
protection resources

■ Compliance Manager—A risk assessment tool that assesses and scores

an organization’s regulatory compliance, based on multiple published
standards

■ Industries & Regions—Provides documents containing compliance

information for specific industries, such as education, financial services,
government, health care, manufacturing, and retail, and specific
countries, including Australia, Czech Republic, Germany, Poland,
Romania, Spain, and the United Kingdom

■ Trust Center—Links to the Trust Center site, which provides

documentation on the means by which Microsoft supports security,
privacy, compliance, and transparency in its cloud services

Compliance Manager

Compliance Manager is a risk

assessment tool that allows an
organization to track and record the
activities they undertake to achieve
compliance with specific certification
standards. An assessment of an
organization’s compliance posture is
based on the capabilities of the
Microsoft cloud services and the ways
that the organization makes use of
them, as compared to an existing
standard, regulation, or law.

The home page for the Compliance

Manager tool contains a dashboard
that displays tiles representing the
assessments of the selected
components against different
standards, as shown in Figure 1-59.
Each tile specifies a cloud service and
the specific standard to which it is
being compared. The results of the
comparison are stated as a numerical
score.
FIGURE 1-59 A Compliance
Manager tile

Selecting a tile displays a list of the

cloud services being tested for the
assessment, as shown in Figure 1-60,
along with the results for each
individual control. The controls are
broken down into those for which
Microsoft is responsible and those for
which the customer is responsible.
Each control entry contains a
reference to a section or article in the
standard that corresponds to the
control; information about who tested
the control and when; and the results
of the test, expressed as an individual
Compliance Score value.

FIGURE 1-60 A cloud service

assessment in Compliance Manager

Auditing

Power Platform also supports

auditing, which is another way of
monitoring compliance with data
access regulations. Auditing captures
instances of specific activities and
saves them to a log file, which
administrators can review to monitor
data access by specific users,
modifications of security roles,
changes made to entities and fields,
changes made to sharing privileges,
and the time and place of updates.

To allow auditing and access auditing

logs, an administrator expands the
Audit and logs heading on an
environment’s Settings page in the
Power Platform admin center.
Selecting Audit settings opens the
Auditing tab on the System Settings
page of the Dynamics 365 admin
center, as shown in Figure 1-61.

FIGURE 1-61 The Auditing tab of the

System Settings page in the Dynamic
365 admin center

Other controls on the environment’s

Settings page allow administrators to
manage the logs and view individual
entries, as shown in Figure 1-62.

FIGURE 1-62 Audit log detail

CHAPTER SUMMARY
■ The Power Platform tools provide users with the ability to perform
three key actions on their data: analyze, act, and automate.

■ Power BI is a data analytics service that allows users to discover and

gather data from local and cloud sources and then visualize and share
that data.

■ Power Apps is a development platform that allows users to act on their

data by creating web and mobile applications without writing code.

■ Power Automate is an automation service that allows users to trigger

complex processes and workflows.

■ Power Virtual Agents is a service that allows users to create chatbots

using a graphical interface with no coding.

■ Power Platform provides connectivity both within and among the

various applications and services in Dynamics 365, Microsoft 365,
Microsoft Azure, and other third-party products.

■ The Power Platform tools—Power BI, Power Apps, Power Automate,

and Power Virtual Agents, along with their underlying components
(Common Data Service, Data Connectors, and AI Builder)—run as
individual services, meaning that they are cloud-based software products
that are hosted by Microsoft Azure on a software as a service (SaaS) basis.

■ All of the Power Platform tools rely on Azure Active Directory for user
accounts and licensing.
 ■ The Power Platform admin center provides administrative access to
the tenant’s existing environments, as well as the ability to create new
ones.

■ Compliance Manager is a risk assessment tool that allows an

organization to track and record the activities they undertake to achieve
compliance with specific certification standards.

THOUGHT EXPERIMENT

In this thought experiment,

demonstrate your skills and
knowledge of the topics covered in
this chapter. You can find the answer
to this thought experiment in the next
section.

Ralph is the sole IT administrator for

Wingtip Toys, which has six offices in
different cities. The offices have
always operated independently, with
each one maintaining its own
financial information using Excel
workbooks. The company executives
are concerned about the security of
their financial data. This is one of the
reasons each of the six offices
maintains its own Excel workbooks.
Because of this arrangement, creating
a picture of the company’s overall
financial health has always been a
problem. Each year, an outside
accounting firm compiles the data
from the six offices into a
comprehensive report, a process that
is expensive and time-consuming and
that generates a financial picture that
is largely out of date.

Ralph has been asked to devise a

solution that will provide the
company executives with an overall
financial picture of the entire
company that is updated on a
continual basis. Having seen materials
on the Power BI service, Ralph thinks
that it might help him to accomplish
his task.

Based on Ralph’s requirements and

your knowledge of the Power BI
service, which of the following are
true statements?
 1. 1. Power BI is capable of accessing data from six different Excel
workbooks at different locations and combining the data into a single
financial report display that is accessible from any Internet device.

2. 2. Power BI can access the Excel data from the six sites without any
possible danger of the original files being modified or damaged.

3. 3. Ralph can use Power BI Desktop to create new reports on his

Android smartphone and publish them to the Power BI service.

4. 4. Ralph must manually update the Power BI reports he creates to

make sure that the data displayed is current.

THOUGHT EXPERIMENT
ANSWERS

This section contains the solution to

the thought experiment. Each answer
explains why the answer choice is
correct.

1. 1. True. Power BI provides access to more than 200 data sources that
allow designers to obtain data from Excel workbooks on local network
computers, as well as network services, such as SQL databases and
cloud-based services, such as SharePoint and Google Analytics.

2. 2. True. Power BI consists of services, applications, and connectors

that can access data from multiple sources and display it in various
ways, but Power BI does not manipulate or modify the data in any
way. Whether a user is a designer using Power BI Desktop to model
data or a consumer using the Power BI reading view to display the
published data, nothing that either type of user does can possibly
modify or delete the underlying data itself.

3. 3. False. Power BI Desktop is a free Windows application that

designers can use to create Power BI content and publish it on the
Power BI Service for consumers to use. It cannot run on an Android
smartphone.

4. 4. False. After a designer connects to a data source, creates Power BI

content, and publishes it to the service, the connection to the source
remains in place and the published data is updated automatically as
the source data changes. This allows users to track information on a
continual basis.
Chapter 2

Identify the core

components of Power
Platform
Microsoft Power Platform consists of
primary applications, such as Power
BI, Power Apps, Power Automate, and
Power Virtual Agents. However, there
are also underlying technologies that
all the applications can use, including
the Common Data Service database, a
collection of data connectors, and the
AI Builder automation and
intelligence engine, as shown in
Figure 2-1.

FIGURE 2-1 Microsoft Power

Platform components

Skills covered in this chapter:

■ 2.1: Describe Common Data Service

■ 2.2: Describe connectors

■ 2.3: Describe AI Builder

SKILL 2.1: DESCRIBE COMMON

DATA SERVICE

Common Data Service is a cloud-

based data storage solution that all
the Power Platform applications can
use to maintain their data in a secure,
manageable environment. The
Common Data Service was originally
designed for use with Dynamics 365
applications, such as Sales and
Customer Service. Therefore, Power
Platform developers can use their
existing Dynamics 365 business data,
logic, and rules when creating new
content in Power BI, Power Apps, and
Power Automate.
 This skill covers how to:

■ Describe the Power Apps user experience

■ Describe entities, fields, and relationships

■ Describe use cases for solutions

■ Describe use cases and limitations of business rules

■ Describe the Common Data Model (CDM)

■ Describe how to use common standard entities to describe people,

places, and things

Describe the Power Apps user experience

Power Apps and the other Power

Platform tools require data for
developers to work with, and they are
all able to connect directly to many
different data sources, including local
files, network resources, and cloud-
based services.

Storing app data in Common Data Service

Depending on the nature of the app

they are building, it is common for
developers to have to connect to
multiple data sources to gather the
information they need. This can mean
accessing multiple sites,
authenticating with multiple accounts,
and updating multiple data points at
frequent intervals. Common Data
Service can simplify this data
gathering model by allowing
developers to store the data from the
different sources in a single protected
place, in an integrated form. The data
stored in Common Data Service is
then available to any of the Power
Platform tools, along with any
Dynamics 365 data that is also stored
there.

For example, when an organization

relies heavily on data stored in many
Excel workbooks, importing them one
time into Common Data Service can
be more convenient than connecting
to each one repeatedly every time an
app is revised or updated. When
importing data into Common Data
Service, developers can model and
transform the data using Power
Query, just as they can when
importing data using Power BI.

Need More Review? Data Modeling and

Transformation

For more information on data

modeling and transformation,
see “Skill 3.2: Connect to and
consume data” in Chapter 3,
“Describe the business value
of Power BI.”

As with direct connections between

apps and data sources, Common Data
Service can synchronize with the data
sources at regular intervals to keep
the stored data updated. The apps
that use the Common Data Service
data can then be updated with the
latest information as well.

Using Common Data Service with canvas and

model apps

As mentioned in Chapter 1, “Describe

the business value of Power
Platform,” Power Apps supports two
basic app types for internal users:
canvas and model apps. (A third type,
portal apps, is intended to create
websites for external users.)

Canvas apps are relatively simple and

give the developer a great deal of
control over the user experience the
app provides. Power Apps offers
canvas apps with standard functions
such as read, write, search, and delete
based on the structure of the data
used by the app. Developers can use
Power Platform connectors to access
data sources directly, or they can use
Common Data Service. It is possible
to create more complex canvas apps,
but the configuration process can
become time-consuming for the
developer.
Model apps are typically more
complex than canvas apps, and they
always use Common Data Service as a
data source. Model apps also have less
flexibility as far as the user experience
is concerned; they use the Dynamics
365 framework. After the developer
has created the data model, Power
Apps generates a user interface that is
appropriate for it. In fact, some of the
Dynamics 365 Customer Engagement
modules are essentially model-driven
Power Apps. This makes it easier for
developers to create more complex
apps than it would be to manually
create them from a blank canvas.

Describe entities, fields, and relationships

Common Data Service is a cloud-

based data storage solution, which
means it is available to any users with
internet access and appropriate
credentials. As with most of
Microsoft’s cloud-based products,
Common Data Service uses Azure
Active Directory (AAD) for user
authentication and authorization.
Organizations that are Microsoft 365
subscribers can use their same user
accounts to access Common Data
Service data; Dynamics 365
subscribers are already accessing their
Common Data Service data with their
AAD user accounts.

Power Platform developers can create

multiple Common Data Service
database instances to accommodate
the needs of various apps and users.
Each database instance can support
up to 4 terabytes of storage;
additional storage is also available for
purchase.

Using entities

When a developer creates a database

instance in Common Data Service, it
consists of a standard set of entities,
with each entity having a standard set
of fields. An entity is the Common
Data Service equivalent of a table in
other database management systems.
A default Common Data Service
instance has a base set of standard
entities, as shown in Figure 2-2, any
of which the developer can select and
populate with data from an outside
source.

FIGURE 2-2 Standard entities in a

Common Data Service instance

In addition to the standard entities

created with every Common Data
Service instance, developers can
create custom entities to suit the
requirements of specific business
applications, assuming that none of
the standard entities are suitable. It is
possible to rename a standard entity if
that makes it more suitable to the
application that will use it.

Creating a custom entity is simply a

matter of clicking the +New entity
button on the Entities screen in the
Power Apps portal to open the dialog
box shown in Figure 2-3, and
supplying a name for the entity. After
expanding the More settings header,
the developer can specify the entity
type and the ownership option. After
the developer has created the new
entity in the Power Apps portal, they
can create custom fields within it.
 ​

FIGURE 2-3 New entity dialog box

in the Power Apps portal

Aside from the Standard entity type,

the developer can also choose the
Activity entity type, which is an entity
that can manage tasks for which it is
possible to create a calendar entry,
such as appointments, phone calls,
faxes, and emails.

The other option for the Standard

entity type is its ownership, which has
the following options:

■ User or team—Actions that developers can perform on this entity’s

records are controlled at the user level. User or team ownership is the
only possible option for Activity entities.

■ Organization—Access to the data stored in the entity is controlled at

the organization level.

Note Complex and Restricted Entities

Apart from standard and

custom entities, Common Data
Service also supports two
other types of entities:
complex entities and
restricted entities. Complex
entities include real-time
workflows, plug-ins, or other
types of server-side business
logic. Restricted entities
 typically contain configuration
data for specific products.
Both of these entity types are
typically not used by Power
Apps citizen developers and
have licensing requirements
that go beyond the Power
Apps/Power Automate Plan 1
license needed for standard
and custom entities. For
complex entities, users must
have a Power Apps/Power
Automate Plan 2 license. For
restricted entities, users must
have a license for the specific
Dynamics 365 product that
uses the entity, such as
Dynamics 365 Sales or
Customer Service.

Using fields

Fields are the attributes within an

entity that contain specific types of
data. If an entity is the equivalent of a
table, then a field is the equivalent of a
column in the table, which contains a
particular data point for each record,
represented by a row in the table. For
example, every entity has an Address
field by default, which is configured
with a data type called Multiline Text,
indicating that every value for that
field can consist of one or more lines
of plain text. Other fields might have
data types such as Whole Number,
Date and Time, or Phone.

Just as a standard set of entities exists

in every database instance, a standard
set of fields exists in every entity, as
shown in Figure 2-4. Depending on
the entity, there can be just a few
standard fields or over a hundred.
 ​

FIGURE 2-4 Standard fields in a

Common Data Service entity

Developers can often use the standard

fields for most purposes, but when
they cannot, it is possible to create
customized fields. Clicking the +Add
field button on an entity page in the
Power Apps portal opens the Field
properties dialog box, as shown in
Figure 2-5.

FIGURE 2-5 Field properties dialog

box in the Power Apps portal

Exam Tip

Common Data Service uses many

of the same data structures as
other database management
engines, but it sometimes uses
different names for them. For
example, what might be called a
 table in another database is called
an entity in Common Data Service.
Candidates for the PL-900 exam
must be conscious of the
possibility for variations in
terminology in their study
materials.

Understanding relationships

Depending on the nature of the app a

developer is creating and the data that
it will use, it might be a good idea to
create multiple entities to hold
different types of data, rather than
store many different data types in a
single entity.

For example, in the case of an order

entry app, the developer might need
to maintain a list of incoming invoices
and a list of the products ordered on
each invoice. The database for this
app would therefore need—at
minimum—records for the invoices
and records for the products ordered.
There would presumably also need to
be records for customer information
and records for an inventory of
products. Storing all of this
information in a single entity (or
table) would be complicated at best.

To better organize the data for the

app, it would therefore be preferable
to create multiple entities and
establish relationships between them.
If the developer creates separate
entities for the invoices and the
products ordered, there could be said
to be a one-to-many (also called a
parent/child or 1:N) relationship
between the two entities. The invoice
entity would be the one (or the
parent), and the products entity could
contain as many product records (or
children) as are needed for each
invoice.
In the same way, the invoice entity
can have a many-to-one (N:1)
relationship to an entity containing
customer information. Each customer
can have many invoices, but each
invoice is associated with only one
customer. This type of entity
relationship appears as a field type
called a lookup field.

Common Data Service also supports

many-to-many (or N:N) relationships
between entities, in which many
records in one entity are associated
with many records in another entity,
in what are known as peer
relationships.

As mentioned earlier, the standard

entities provided by Common Data
Service are sufficient for the needs of
most developers and their apps, and
the relationships between the entities
are already in place. Selecting any
entity in the Power Apps portal and
selecting the Relationships tab
displays the existing relationships and
their types, as shown in Figure 2-6.

FIGURE 2-6 The Relationships tab

for the Customers entity in the Power
Apps portal

From this screen, it is also possible for

developers to create new relationships
by clicking the +Add relationship
button and choosing Many-to-one,
One-to-many, or Many-to-many, to
open a dialog box like the one shown
in Figure 2-7.
 ​

FIGURE 2-7 The One-to-many

dialog box in the Power Apps portal

Describe use cases for solutions

One of the basic design principles of

the Common Data Service is the
ability to customize the database to
suit specific applications. The
extensions that developers create,
package, and deploy to the Common
Data Service are called solutions. A
solution consists of all the
customizations made to the Common
Data Service, including any
modifications that developers might
make to an existing solution. The
entire solution is packaged as a single
file that developers can distribute and
import into other environments.

Solutions can contain a variety of

components generated by the Power
Platform tools, including Power Apps
canvas apps and model-driven apps,
Power Automate flows, custom
connectors, and Common Data
Service entities. However, solutions
do not contain any business data.

Developers can create two types of

solutions, as follows:

■ Unmanaged—Intended for development environments in which

modifications are being made to the solution. Developers can export an
unmanaged solution as either a managed or unmanaged solution. After a
developer imports an unmanaged solution, deleting the solution causes
the solution file to be deleted, but the customizations applied to the
environment remain in place.
 ■ Managed—Intended for nondevelopment situations, such as test and
production environments. Developers cannot export a managed solution
or edit the components in a managed solution directly; they must first
add the components to an unmanaged solution, which is editable.
Deleting a managed solution causes all of the customizations included in
the solution to be removed from the environment.

The typical progression is for

developers to create and refine an
unmanaged solution in a development
environment and then export it as a
managed solution for deployment in a
test environment and later a
production environment, as shown in
Figure 2-8.

FIGURE 2-8 Development

progression using unmanaged and
managed solutions

To create a solution, a developer clicks

the New solution button on the
Solutions page in the Power Apps
portal to open the dialog box shown in
Figure 2-9. After the solution is
created, the developer can then create
components or add existing ones.
Developers can employ solutions in a
variety of use cases, including
application lifecycle management and
business process flows.
 ​

FIGURE 2-9 The New solution

dialog box in the Power Apps portal

Describe application lifecycle management

Application lifecycle management

(ALM) is a cyclical paradigm for the
development, governance, and
maintenance of applications, as
illustrated in Figure 2-10. Power
Platform supports an ALM strategy
that uses Power Apps, Power
Automate, and Common Data Service
components packaged as a solution.

FIGURE 2-10 The lifecycle of an

application

By packaging the components of an

ALM strategy as a solution,
administrators can import them into
the Common Data Service in other
environments. This allows developers
in those other environments to access
the ALM components when
developing their own apps and flows.

Describe business process flows

Business process flows are tools that

allow administrators to ensure that
users follow specific procedures when
performing certain tasks. For
example, order entry operators
working in a call center might use a
business process flow to ensure that
they gather all the necessary
information from the caller and
record it in the correct places.

A business process flow organizes a

task by breaking it down into a series
of stages, with each stage consisting of
multiple steps. When a developer
creates a new business process flow, a
working canvas appears like that
shown in Figure 2-11. The stages run
horizontally across the canvas and the
steps vertically beneath each stage.
The developer can drag and drop flow
elements from the Components list in
the right pane onto the canvas at any
appropriate location.

FIGURE 2-11 Canvas for creating a

business process flow

When users run a business process

flow, they see an interface like that
shown in Figure 2-12, in which the
flow leads them through its stages,
providing text boxes and drop-down
lists in which they can supply the
necessary data. The developer can
configure the flow to not permit users
to proceed to the next stage until they
have completed the present one. This
ensures that all the required elements
of the business process are completed.

FIGURE 2-12 Business process flow

user interface

Business process flows, by

themselves, do not provide any
advanced intelligence. They are
designed to guide users through a
series of tasks—typically involving
data entry—and bring them to a
specific outcome, such as the
completion of an order entry or a
customer interaction.

However, it is possible for developers

to use business process flows to apply
data supplied by users to forms that
initiate automation using business
rules, Common Data Service
workflows, and form scripts. Business
process flows can trigger server events
based on the data supplied by the
user, such as the generation of email
messages.

On the client side, user input can

trigger the appearance or
disappearance of fields, automatic
movement to the next stage of the
flow, or a shift to a different flow
altogether. For example, when a user
indicates in an order entry flow that a
customer requires a product
installation, the focus can shift to a
scheduling flow. After the scheduling
of the installation is complete, the
focus can shift back to the order entry
flow for completion.

There are limits to the size and

complexity of business process flows,
including the following:

■ A business process flow can have no more than 30 stages.

■ A single entity can have no more than 10 business process flows

activated at one time.

■ A single business process flow can involve no more than five entities.

Describe use cases and limitations of

business rules

Business rules enable developers to

implement logic on data stored in
Common Data Service. Because the
rules apply to the data, and not to a
specific app, they take effect however
the data is used. For example, if the
value of the Country field in an entity
is entered as Canada, a business rule
can enable a six-digit alphanumeric
Postal Code field and hide the five-
digit numeric Zip Code field used for
U.S. addresses.

Business rules consist of conditions

and actions. Conditions are
circumstances that must be met for
the rule to apply, and actions are the
procedures taken when the
circumstances of the condition are
met. When a developer selects an
entity in the Power Apps portal,
selects the Business Rules tab, and
clicks Add business rule, a New
business rule canvas appears, as
shown in Figure 2-13.

FIGURE 2-13 A New business rule

canvas in the Power Apps portal
As with a business process flow,
developers can drag elements from
the Components pane to the canvas.
Selecting an element on the canvas
causes the Properties interface for
that element to appear in the right
pane. The combination of conditions
and actions creates an IF/THEN logic
statement that appears in the
Business Rule (Text View) box on the
canvas.

For a condition, the developer

configures one or more rules
specifying when the actions should
occur. In the figure, the condition
calls for the Country field to have the
value Canada. When that condition is
met, the specified actions occur. The
developer can then create actions that
cause the U.S. Zip Code field to be
hidden and the Canadian-format
Postal Code field to be shown.

Conditions can be more complex, with

multiple rules that use Boolean
and/or operators to specify whether
both conditions must be met for the
actions to apply or either one of the
conditions. The rule can also include
multiple actions that execute when
the condition is met.

The most common functions of

business rules are to simplify the
process of supplying data for users
and verify the accuracy of the data
that users supply. To that end,
developers can create rules that set
values for fields, clear the values from
fields, and validate the data entered
into fields. In model-driven apps
(only), business rules can also show,
hide, enable, and disable fields. For
example, when users are required to
supply their annual income in a field,
a rule can enable additional fields for
verification if the income exceeds a
specified amount.
Describe the Common Data Model (CDM)

As discussed earlier in this chapter,

Common Data Service can function as
a database for the Power Platform
tools, as well as for Dynamics 365.
While Common Data Model sounds
similar to Common Data Service, it is
not the same thing.

CDM is not a database manager or

any sort of data storage technology.
Instead, the Common Data Model
(CDM) is a Microsoft initiative that
defines a shared data language,
consisting of a unified system of
schemas and metadata. The objective
behind CDM is to create a
standardized format for data sharing
and storage that allows applications
and services to share data without the
need for custom implementations.

It is common for organizations to

have many applications for different
purposes, each of which includes its
own database. In some cases, users
maintain their own databases that are
not linked to an application, such as a
salesperson’s Excel spreadsheet
containing contacts and leads.
Problems arise when there is a need to
share or transfer data between these
many databases. Each share or
transfer requires a separate procedure
to ensure that individual data points
are saved to the correct locations.

As a shared data model, CDM

provides a consistent format for data
storage. When all of the organization’s
databases are based on the flexible
CDM format, then the applications
can share or transfer data freely
without any special formatting
considerations.

The primary components of the CDM

are a metadata system that provides
the means to define data types and a
continually updated set of
standardized data schemas that define
commonly used types of business
data. The schemas include predefined
entities and attributes for many of the
data types that organizations use,
including sales, service, and finance,
as shown in Figure 2-14.

FIGURE 2-14 Common Data Model

schemas

Need More Review? Common Data Model Documents

on GitHub

Microsoft maintains and

continually updates
documents defining the
Common Data Model on their
GitHub repository at
https://github.com/Microsoft/
CDM.

Many of Microsoft’s applications and

services store their information in
databases that conform to the CDM
standard, including the Common Data
Service, as used in Dynamics 365 and
Power Platform; dataflows in Power
BI and Power Apps; Graph data
connect in Office 365; and Azure
Synapse. All these applications and
services use CDM as their native
metadata structure and can freely
share the data they store in CDM-
based storage technologies. Many
other software developers and
vendors use the CDM format as the
basis for their products as well.

These applications and services store

their CDM-formatted data in Azure
Data Lake Storage in folders that
conform to the standard CDM
metadata structures. Folders that
contain the following files are
Common Data Model folders:

■ model.json

■ .cdm.json

■ *.manifest.cdm.json

Describe how to use common standard

entities to describe people, places, and
things

As mentioned earlier in this chapter,

creating an instance of Common Data
Service in an environment
automatically populates the database
with a collection of standard entities
that are based on the Common Data
Model and designed to support the
most commonly used types of
business data, including the following:

■ Account

■ Address

■ Appointment

■ Attachment

■ Business Unit

■ Contact

■ Currency

■ Email

■ Feedback

■ Letter

■ Mailbox

■ Organization

■ Phone call

■ Position

■ Task

■ Team

■ User

These entities represent people,

places, and things, elements that
many businesses use on a daily basis
when communicating both internally
and outside the organization. Each
entity includes fields appropriate to
its subject, as shown in Figure 2-15.
The standard entities are all
customizable also, making it possible
for developers to add new fields or
modify existing ones as needed.
 ​

FIGURE 2-15 Fields in the Account

entity in the Power Apps portal

Need More Review? Standard Entities

For more information on

standard entities, see
“Describe entities, fields, and
relationships,” earlier in this
chapter.

SKILL 2.2: DESCRIBE

CONNECTORS

Connectors are the Power Platform

components that allow Power Apps
and Power Automate to interact with
outside applications, services, and
data files and utilize their data. Well
over 200 public connectors are
available to Power Platform users, and
for those applications and services
that are not supported, it is possible
for developers to create custom
connectors.

A connector is a proxy wrapper that

Power Platform tools use to access an
application programming interface
(API) provided by an application or
service. Many applications and cloud
services have the necessary APIs, and
the Power Platform connectors
function as proxies, or intermediaries
between the outside APIs and the
internal Power Platform tools. The
connector, in its role as a proxy,
authenticates to the outside
application or service and then
provides Power Apps and Power
Automate with access to its data.
 This skill covers how to:

■ Describe triggers including trigger types and where triggers are

used

■ Describe actions

■ Describe licensing options for connectors including standard or

premium tier

■ Identify use cases for custom connectors

Describe triggers including trigger types

and where triggers are used

Triggers are components in Power

Automate that cause a flow to begin
running. Some triggers can be
schedule based, so that the flow
launches at a specific date and time;
event based, so that the flow launches
when a user performs a specific task;
or even manual, in which a user
launches a flow by clicking or tapping
a button. However, there are also
triggers associated with data
connectors, so that changes involving
a data source cause a flow to launch.

For example, the connector for

SharePoint includes triggers that can
launch a flow when an item is created,
when an item is created or modified,
or when a file is created in a folder, as
shown in Figure 2-16.

FIGURE 2-16 The Build an

automated flow dialog box from the
Power Automate portal

When a developer creates an

automated flow—that is, a flow that is
launched by an outside event—two
types of triggers are available:

■ Polling triggers—Connect to the outside data source at scheduled

intervals to check for new data, launching the flow using that new data as
input when it becomes available
 ■ Push triggers—Listen at a server endpoint for notifications that a
specific event has occurred on an outside application or service,
launching the flow when the notification arrives

When developers create instant flows

or scheduled flows, they still use
triggers, but these triggers function
autonomously. An instant flow uses a
trigger that is tied to a button or other
control in an app that requires user
interaction to launch the flow.
Scheduled flows use a trigger that the
developer configures to activate at a
specific date and time, using the
interface shown in Figure 2-17.

FIGURE 2-17 The Build a scheduled

flow dialog box from the Power
Automate portal

Describe actions

Actions are specific modifications

made to the data provided by an
outside application or service. In
Power Automate, actions are usually
the result of a trigger, but developers
can use them in Power Apps as well.
For example, when a developer
creates a manual trigger in a Power
Automate flow, the next step is to
select an action that will be the result
of the trigger, as shown in Figure 2-
18. Apps and flows can include
multiple actions using different
connectors to perform a sequence of
tasks.
 ​

FIGURE 2-18 The Choose an action

dialog box in the Power Automate
portal

Actions can cause an application or

service to perform a task, such as send
an email, or modify the source data in
some way. For example, Figure 2-19
contains the interface for an action
that deletes a row from a specific
Excel spreadsheet.

FIGURE 2-19 The Delete a row

action for Excel in the Power
Automate portal

The developer uses the interface to

specify the location of the Excel file,
identify the worksheet in the file on
which the action will be performed,
and specify the row to be deleted.
Other actions for the Excel connector
make it possible to get data from a
worksheet or update a worksheet with
new data supplied by the app or flow.
The actions for the many other
connectors depend on the capabilities
of the application or service.

Describe licensing options for connectors

including standard or premium tier

As mentioned earlier, Power Platform

provides connectors for over 200
applications and services, and
Microsoft is regularly adding new
ones. There are two classes of
connectors, standard and premium,
access to which are based on the
Power Apps or Power Automate
license in use.

Standard connectors are available to

all licensees of Power Apps and Power
Automate, regardless of the plan or
product through which the user
obtained the license. The standard
connectors include those for many of
the Microsoft 365 and Office 365
applications and services, as well as
popular social media services, a
sampling of which are shown in
Figure 2-20.

FIGURE 2-20 Sampling of standard

connectors in Power Automate

The connectors designated as

premium are available to licensed
users of the standalone versions of
Power Apps (both the per user and the
per user, per app plans) and Power
Automate (both the per user and per
flow plans), as well as Dynamics 365
users. The premium connectors
feature those for many commercial
Microsoft and third-party services,
including SQL Server and Dynamics
365. A sampling of the premium
connectors is shown in Figure 2-21.
 ​

FIGURE 2-21 Sampling of premium

connectors in Power Automate

Power Apps standalone licenses

include Power Automate capabilities,
as long as the Power Automate flows
exist in the context of a Power Apps
application. These contextual flows
are permitted to use whatever
standard and premium connectors are
provided with the Power Apps license.
Standalone flows that are not part of a
Power Apps application are not
supported by the Power Apps license;
a standalone Power Automate license
is required.

Licensed Microsoft 365 and Office 365

users have access to the standard
connectors in Power Apps and Power
Automate, but they do not have access
to premium connectors. To gain
access to the premium connectors,
they need a standalone Power Apps
and/or Power Automate license as
well.

Exam Tip

Candidates for the PL-900 exam

should be aware of the fact that,
despite their being referred to by
the single name Power Platform,
the Power BI, Power Apps, Power
Automate, and Power Virtual
Agents tools are separate
products, each requiring its own
license and with its own licensing
terms. For a full description of the
licensing terms for Power Apps,
Power Automate, and Power
 Virtual Agents, see the licensing
guide available at
https://go.microsoft.com/fwlink/?
linkid=2085130.

Identify use cases for custom connectors

As mentioned earlier, a connector is a

wrapper that surrounds a REST API
supplied by the application or service
that will be the data source. Power
Platform provides connectors for a
great many applications or services,
but certainly not for every one. For
developers that require access to data
sources for which there are no public
connectors available, it is possible for
them to create their own custom
connectors.

When a developer creates a custom

connector, it is part of the current
working environment and is usable
only by the apps and flows operating
in that same environment. It is also
necessary for consumers running apps
or flows that use custom connectors to
have their own credentials for
authentication to the data source, if
the data source requires them. Unlike
with public connectors, there is no
way for consumers of a shared app or
flow using custom connectors to
inherit credentials supplied by the
developer.

Depending on the application or

service for which the developer will
create a custom connector, there
might or might not be an existing API
with which the connector can
communicate. A third-party
application or service might already
have an API in place. If not, the
developer might have to discuss with
the third party the possibility of their
creating one. For an internally
developed application or service
without an API, the developer might
have to create one using a tool such as
Azure Functions, Azure Web Apps, or
Azure API Apps.

There are several ways in which a

custom connector can communicate
with the API. When a developer runs
the Custom Connector Wizard, the
following options are provided:

■ Create from blank

■ Create from Azure service

■ Import an OpenAPI file

■ Import an OpenAPI from URL

■ Import a Postman collection

OpenAPI (formerly known as

Swagger) and Postman are definition
file formats that provide the
communication information the
custom connector needs. When
creating a custom connector from
scratch (using the Create from blank
option), the developer is led by the
wizard through four stages:

1. General—Prompts for an icon and color for the connector tile and the
host name for the API, as shown in Figure 2-22

FIGURE 2-22 The General tab of the Custom Connector

Wizard

2. Security—Prompts for the authentication method the connector

should use to access the API: Basic authentication (as shown in Figure
2-23), API Key, or OAuth 2.0

FIGURE 2-23 The Security tab of the Custom Connector

Wizard

3. Definition—Provides the interface for creating the connector’s actions,

triggers, and policies, as shown in Figure 2-24
 ​

FIGURE 2-24 The Definition tab of the Custom Connector

Wizard

4. Test—Provides a platform for testing specific operations in the custom

connector, as shown in Figure 2-25

FIGURE 2-25 The Test tab of the

Custom Connector Wizard

After developers have created custom

connectors, they can share them with
users inside their organization.
Sharing an app or flow that uses a
custom connector makes it accessible
to the recipients of the share.
Developers can also share their
custom connectors with other users by
selecting Invite other user from the
Custom connectors page to display the
interface shown in Figure 2-26.

FIGURE 2-26 The Share tab of a

custom connector

To share custom connectors with

users outside of the organization,
developers must submit it for
certification by Microsoft, which
validates the connector’s functionality
and content. The connector then
undergoes a testing phase in a preview
area, and when testing is complete, it
is deployed for public access.
Connectors that are certified and
published by Microsoft must be
released as open source software.

SKILL 2.3: DESCRIBE AI BUILDER

AI Builder is a relatively recent

product designed to add intelligence
to the apps and flows created in Power
Apps and Power Automate. AI Builder
enables apps and flows to perform
interpretive tasks using data stored in
the Common Data Service, such as
predicting yes/no outcomes based on
historical data patterns, gathering
data from forms, classifying text and
applying labels or tags to it, counting
and identifying objects depicted in an
image file, and organizing data
scanned from business cards.

This skill covers how to:

■ Identify the business value of AI Builder

■ Describe models including business card reader, detection model,

form processing model, and prediction model

■ Describe how Power Apps and Power Automate can consume AI

Builder data

Identify the business value of AI Builder

From a business perspective, AI

Builder enables organizations to
perform large-scale data gathering
activities without manual
intervention, eliminating the need for
people to perform repetitive data
entry and classification tasks.

For example, an organization can use

the object detection model to perform
inventory and stock-taking tasks. By
taking photos of warehouse shelves
and feeding them to an app
containing an AI Builder model, the
app can count the number of objects
in the photos and also identify even
similar-looking objects, such as
containers with different labels. The
app can then tabulate the data and
store it in a Common Data Service
database.

Retaking the same photos later can

then generate revised data and enable
the app to report on the products that
have been sold and that need to be
reordered. Instead of multiple
workers needing hours or days to
count the products on the shelves, one
person can simply take the necessary
photographs, and the app containing
the AI Builder model does the rest.

As shown in Figure 2-27, AI Builder

includes a number of prebuilt models
that developers can use immediately,
such as the Business Card Reader
model. It also allows developers to
create customized versions of AI
models, such as the Object Detection
model, which they build and train
using their own data. Microsoft is
currently in the process of developing,
previewing, and releasing additional
AI Builder components that enhance
both its turnkey and custom
capabilities.

FIGURE 2-27 The AI Builder Build

screen in the Power Automate portal

Describe models including business card

reader, detection model, form processing
model, and prediction model

To use AI Builder, developers choose

from a collection of models that define
scenarios in which an app can apply
artificial intelligence to a business
task. There are prebuilt model types
that define common tasks and are
ready for immediate use, as well as
custom model types that define basic
AI functions, which developers can
build and train with their own data.
The models included with AI Builder
as of this writing are described in the
following sections.

Prebuilt models

The prebuilt models included in AI

Builder are designed to perform
specific tasks common to many
businesses and do not require
developers to build and train the
model before they can use it. They
appear as tiles in the Build screen in
AI Builder in a section called Get
straight to productivity. The prebuilt
models currently supplied with AI
Builder are as follows:

■ Business Card Reader—Extracts detailed name, address, and contact

information from a JPEG, BMP, or PNG image of a business card (up to 6
MB in size), regardless of the card’s print layout. In a flow, the model
creates a manual or automatic trigger and two actions, as shown in Figure
2-28: Predict, in which AI identifies the data appropriate to each of the
20 fields supported by the model, and Create a new record, which creates
a record in the Contacts entity of the Common Data Service and inserts
each identified datum from the card image into the correct field.

FIGURE 2-28 AI Builder Business

Card Reader model

■ Category Classification—Accepts textual input from email messages

and evaluates the language to determine the category in which the text
should be placed. In the sample automated flow, as shown in Figure 2-29,
incoming emails trigger the flow, convert the HTML in the email message
to plain text, and feed the text to the model. The model uses AI to select
an appropriate category for the text and sends it to a separate case for
that category, which generates an email routed to appropriate recipients.
In this prebuilt model, the two categories supplied are Documentation
and Price & Billing, but the developer can create as many additional
categories as needed.
 ​

FIGURE 2-29 AI Builder Category Classification model

■ Entity Extraction—Accepts textual input from email messages and

evaluates the language to identify the entities to which the message
refers. In the sample automated flow, as shown in Figure 2-30, incoming
emails trigger the flow, convert the HTML in the email message to plain
text, and feed the text to the model. The model uses AI to extract
information from the text conforming to any of the 28 specific entities
specified in the model, such as Date and time, City, Email, Weight, and
Phone number.

FIGURE 2-30 AI Builder Entity Extraction model

■ Key Phrase Extraction—Accepts textual input from Yammer messages

and evaluates the language to identify the most important phrases and
add them to an Excel worksheet. In the sample automated flow, as shown
in Figure 2-31, incoming Yammer messages trigger the flow and feed the
text to the model. The model uses AI to extract the phrases from the text
that are the main elements of the message, and then creates new rows in
a specified Excel worksheet and adds the phrases to them.

FIGURE 2-31 AI Builder Key Phrase Extraction model

■ Language Detection—Accepts textual input from email messages,

identifies its predominant language, and routes the email to an
appropriate recipient. In the sample automated flow, as shown in Figure
2-32, incoming email messages trigger the flow and convert the HTML to
plain text. The model then uses AI to identify the language of the text.
Then, the flow’s actions determine the correct recipient for the language,
assign the message the correct two-letter language code, and route the
email to the recipient.
 ​

FIGURE 2-32 AI Builder Language Detection model

■ Sentiment Analysis—Analyzes text to make a determination of

whether its sentiment is positive, negative, or neutral and generates an
email or notification informing a recipient of the result. In one of the
three sample automated flows, as shown in Figure 2-33, new tweets
trigger the flow, which uses AI to determine the sentiment of the tweet
and, if the sentiment is negative, generates an email to a specified user.

FIGURE 2-33 AI Builder Sentiment Analysis model

■ Text Recognition—Scans image files for printed or handwritten text.

In the sample instant flow shown in Figure 2-34, the selection of an
image file causes the AI to scan the image for text and assign the resulting
text to a variable.

FIGURE 2-34 AI Text Recognition model

Although most of these prebuilt

models are designed to be usable as is
in a flow or an app, developers can
also modify them as needed to create
additional actions that utilize the
information produced by the AI
functions. For example, the Language
Detection model contains modules for
English and French only; developers
can add more languages as needed.

Custom models

The Refine a model for your business

needs section of the AI Builder’s Build
screen contains tiles that provide
access to models that developers can
customize for use with their own data
and business needs. Unlike the
prebuilt models, which use AI to make
determinations based on standard
business practices, developers must
build and train the custom models
with their own data and practices. For
example, anyone can use the prebuilt
Business Card Reader model without
modification of the AI, because the
information found on business cards
is predictable. For custom models,
such as Object Detection, the AI must
be trained to recognize images of an
organization’s products before it can
identify them in images accurately.

The custom models provided by AI

Builder include the following:

■ Category Classification—Analyzes text and assigns tags to it

representing categories of any type

■ Entity Extraction—Scans incoming text for specific data elements and

uses those elements to categorize the text

■ Form Processing—Scans forms and extracts the pertinent data for

storage or use by the flow or app

■ Object Detection—Scans image files for recognized objects and

identifies them

■ Prediction—Uses historical patterns of past results to predict future

responses in binary solution sets, such as yes/no, true/false, and go/no go

The process of building and training

one of the custom models requires the
developer to supply training data so
that the AI can learn to perform the
required task. For example, to use the
Category Classification model, the
developer must supply samples of
data that has already been tagged
categorically and a minimum of 10
examples for each category tag. Using
this information, the AI can learn
what kind of data each tag represents
and prepare itself to duplicate the
tagging process on new data supplied
to it. In the same way, the developer
must supply multiple samples of the
same forms for the Form Processing
model and images of the objects to be
identified for the Object Detection
model.

Some of the AI Builder models, such

as Category Classification and Entity
Extraction, are available both as
prebuilt and custom models. The
primary difference between the two
versions is that the prebuilt models
have AI functions that are already
trained with generic data, whereas the
custom models need to be trained
with data supplied by the developer. If
the AI function in the prebuilt model
is satisfactory for a developer’s
particular application, it is possible to
customize the triggers that launch the
flow or the actions performed after
the AI process is completed. To
modify the functionality of the AI, the
developer must use the custom model
and train it with new data.

Describe how Power Apps and Power

Automate can consume AI Builder data

AI Builder models all generate data in

some form or another. The Business
Card Reader model generates
database records containing the
information scanned from the
business cards. The Prediction model
generates a single binary result, such
as a yes or no. The Language
Detection model generates a two-digit
code indicating the language of the
input data. Apps and flows can make
use of this generated data in various
ways.

In some cases, such as the Business

Card Reader and Form Processing
models, their primary function is to
scan data from source documents and
save it by placing individual data
points in the correct fields of a
database record. However, Power
Apps and Power Automate developers
can easily use the data in other ways
as well, such as by adding actions that
forward the data to specific users by
email or with other messaging
applications.

Other AI Builder models are designed

to categorize data by extracting key
phrases or applying tags and labels.
These processes can make it easier to
locate specific types of data at a later
time by searching for specific tags,
labels, or phrases. These processes
also provide additional capabilities to
apps and flows. However, instead of
directing new incoming data to
appropriate recipients based on its
contents, tagging and labeling makes
it possible for apps and flows to locate
specific information in an existing
Common Data Service database by
performing searches for key phrases,
tags, and labels.

CHAPTER SUMMARY
■ Common Data Service is a cloud-based data storage solution that the
Power Platform applications can use to maintain their data in a secure,
manageable environment.

■ The Power Platform tools are able to connect directly to many

different data sources, including local files, network resources, and cloud-
based services.

■ An entity is the Common Data Service equivalent of a table in other

database management systems. A default Common Data Service instance
has a base set of standard entities, which the developer can populate with
data from outside sources.

■ Fields are the attributes within an entity that contain specific types of
data. If an entity is the equivalent of a table, then a field is the equivalent
of a column in the table.

■ An environment is a container for the apps and flows created in Power

Apps and Power Automate, as well as the data they use.

■ Business process flows are tools that allow administrators to ensure

that users follow specific procedures when performing certain tasks.

■ Business rules enable developers to implement logic on data stored in

Common Data Service.

■ Common Data Model (CDM) is a Microsoft initiative that defines a

shared data language, consisting of a unified system of schemas and
metadata. The objective behind CDM is to create a standardized format
for data sharing and storage that allows applications and services to share
data without the need for custom implementations.

■ Connectors are Power Platform components that allow Power Apps

and Power Automate to interact with outside applications, services, and
data files and utilize their data.

■ Triggers are components in Power Automate that cause a flow to begin

 running. Actions are specific modifications made to the data provided by
an outside application or service.

■ AI Builder adds intelligence to the apps and flows created in Power

Apps and Power Automate.

■ To use AI Builder, developers choose from a collection of prebuilt and

custom models that define scenarios in which an app can apply artificial
intelligence to a business task.

THOUGHT EXPERIMENT

In this thought experiment,

demonstrate your skills and
knowledge of the topics covered in
this chapter. You can find answers to
this thought experiment in the next
section.

Ralph is exploring the Power Platform

tools, and he is having trouble
understanding the differences
between the Common Data Model and
the Common Data Service. For each of
the following concepts, specify
whether Ralph should associate it
with the Common Data Model or the
Common Data Service.

1. 1. Functions as a database for the Power Platform tools

2. 2. Consists of a unified system of schemas and metadata

3. 3. Provides a consistent format for data storage

THOUGHT EXPERIMENT
ANSWERS

This section contains the solution to

the thought experiment. Each answer
explains why the answer choice is
correct.

1. 1. Common Data Service. Common Data Service can simplify this

Power Platform data gathering model by allowing developers to store
the data from the different sources in a single protected place, in an
integrated form. The data stored in Common Data Service is then
available to any of the Power Platform tools.

2. 2. Common Data Model. The primary components of the CDM are a

metadata system that provides the means to define data types and a
continually updated set of standardized data schemas that define
commonly used types of business data. The schemas include
predefined entities and attributes for many of the data types that
organizations use, including sales, service, and finance.

3. 3. The objective behind CDM is to create a standardized format for

data sharing and storage that enables applications and services to
share data without the need for custom implementations. When all of
the organization’s databases are based on the flexible CDM format,
then the applications can share or transfer data freely without any
special formatting considerations.
Chapter 3

Describe the business

value of Power BI
Microsoft Power BI is a cloud-based
tool that allows users without coding
skills or experience to create real-time
graphical displays of data from a
variety of sources and publish them to
a cloud service that makes them
accessible to virtually any desktop or
mobile device. The objective of Power
BI is to help users make their data
more accessible by displaying it in
graphs of various types, as shown in
Figure 3-1, rather than as raw data.
The designer of the display can thus
interpret the data to highlight the
information that is most important to
the consumer.

FIGURE 3-1 A Power BI dashboard

Skills covered in this chapter:

■ 3.1: Identify common Power BI components

■ 3.2: Connect to and consume data

■ 3.3: Build a basic dashboard using Power BI

SKILL 3.1: IDENTIFY COMMON

POWER BI COMPONENTS

The process of creating a simple

Power BI dashboard consists of the
following basic steps:

1. Connect to data sources

2. Transform the data

3. Create report visualizations

4. Build the dashboard

5. Publish the dashboard

As dashboard designers work through

these steps, they encounter the
various Power BI components that
can aid them in creating a compelling
dashboard design.

This skill covers how to:

■ Identify and describe uses for visualization controls including pie,

bar, donut, and scatter plots and KPIs

■ Describe types of filters

■ Describe the Power BI Desktop Reports, Data, and Model tabs

■ Describe uses for custom visuals including charts or controls

■ Compare and contrast dashboards and workspaces

■ Compare and contrast Power BI Desktop and Power BI Service

Identify and describe uses for visualization

controls including pie, bar, donut, and
scatter plots and KPIs

Visualizations are the formats

designers can use to display data in a
Power BI dashboard or report. Power
BI provides a large selection of
visualizations to choose from,
including various types of charts,
tables, maps, gauges, apps, and cards.

When creating a Power BI dashboard

or report, the designer must first
connect to a data source and, if
necessary, transform the data. Once
these tasks are done, the designer can
select the visualization that Power BI
will use to display the data from the
Visualizations pane on the right side
of the workspace, as shown in Figure
3-2.

FIGURE 3-2 The Visualizations pane

in the Power BI workspace

Microsoft occasionally adds new

visualizations to this pane, so it might
not appear exactly as shown here.
Some of the visualizations that are
currently available for use include the
following.

Bar and column charts

Bar and column charts display

numerical values as adjacent
horizontal or vertical shapes, making
possible the easy comparison of
relative values, as shown in Figure 3-
3. Typically used for comparisons of
like values, horizontal bars are
preferable for qualitative values such
as distance and speed. Vertical
columns are commonly used for
numerical values representing
quantities, sizes, and costs. However,
these definitions are not absolute.

FIGURE 3-3 Bar and column charts

in Power BI

Power BI provides visualizations

supporting several different types of
bar and column charts, including the
following:

■ Stacked—Charts that combine two or more values in each bar or

column, as shown in Figure 3-4

FIGURE 3-4 A stacked column chart in Power BI

■ 100% stacked—Charts that combine two or more percentages to

display their values out of 100 percent, as shown in Figure 3-5
 ​

FIGURE 3-5 A 100% stacked column chart in Power BI

■ Clustered—Charts that display groups of values as adjacent bars or

columns, as shown in Figure 3-6

FIGURE 3-6 A clustered column chart in Power BI

■ Funnel—Bar charts that display values in descending numerical order,

creating a display that resembles a funnel, as shown in Figure 3-7

FIGURE 3-7 A funnel chart in Power BI

■ Waterfall—Column charts that split a single statistic into sequential

increments, typically representing intervals of time or category, as shown
in Figure 3-8

FIGURE 3-8 A waterfall chart in Power BI

Line charts

Line charts display one or more value

sequences represented by horizontal
lines running from each value to the
next one, as shown in Figure 3-9.
Commonly used for the presentation
of values over time, as in financial
profit and loss charts, the horizontal
(or x) axis traditionally represents the
time interval, such as days, months, or
years.
 ​

FIGURE 3-9 A line chart in Power BI

Combo charts

Power BI supports the combination of

line and column charts into a
composite that overlays line data onto
a series of columns. The combination
of the two chart types makes it
possible to compare data sets that
share the same x-axis, as in Figure 3-
10. In this figure, the line represents
the profit margin for a series of
products and the columns represent
their manufacturing and sales prices.

FIGURE 3-10 A combo chart in

Power BI

Area charts

An area chart is essentially a line chart

with the space between each line and
the x-axis shaded, as shown in Figure
3-11. By using translucent shading,
the chart can display the overlap
between the two sets of values.

FIGURE 3-11 An area chart in Power

BI
Pie charts

A pie chart consists of a circle

resembling a pie divided into two or
more slices shaded in different colors
to represent numerical values, as
shown in Figure 3-12. Designers
typically use pie charts to illustrate
percentages, with the entire pie
representing 100 percent of the
statistic.

FIGURE 3-12 A pie chart in Power

BI

Donut charts, a variation of the pie

chart, consist of a ring (or annulus)
divided into segments in the same
way, as shown in Figure 3-13.

FIGURE 3-13 A donut chart in

Power BI

Scatter plots

Unlike bar, column, and line charts,

which usually dedicate the x-axis to a
time scale, scatter charts (or scatter
plots) use both axes for numerical
data values and indicate data points at
the intersection of two values on the
scale, as shown in Figure 3-14.
 ​

FIGURE 3-14 A scatter chart in

Power BI

A variation on the scatter chart is the

bubble chart, which adds a third data
value by modifying the size of the data
points to represent a third dimension,
as shown in Figure 3-15.

FIGURE 3-15 A bubble chart in

Power BI

Key performance indicators

A key performance indicator (KPI) is a

chart that indicates the progress of a
single data point toward a specific
predetermined goal. A KPI begins as a
standard chart with a time interval on
the x-axis, which represents the trend,
and a data indicator value on the y-
axis. Then the developer specifies a
goal, which is a single value, and the
chart appears as shown in Figure 3-16.

FIGURE 3-16 A key performance

indicator chart in Power BI
The area chart in the background
displays the current trend values, and
in the foreground is the current
numerical value and the goal value,
plus a percentage that specifies how
far off the current trend value is from
the goal.

Cards

In a Power BI dashboard or report, a

card is a tile that contains a single
number in large, easily readable type,
as shown in Figure 3-17. Designers
use a card when there is a single
numerical value important enough to
be displayed by itself.

FIGURE 3-17 A Power BI card

Gauge charts

A radial gauge chart displays a single

value and its relationship to a specific
goal, using a semicircular dial with a
colored indicator representing the
statistic’s current value and a needle
representing its ultimate goal, as
shown in Figure 3-18, similar to that
of an analog fuel gauge on an
automobile dashboard.

FIGURE 3-18 A gauge chart in

Power BI

Key influencers

A key influencers tile allows

consumers to explore the factors that
affect a specific metric. When you
create the visualization and select
fields from the data source, Power BI
performs an analysis and creates a
chart like the one shown in Figure 3-
19. Selecting one of the factors on the
left modifies the column chart on the
right.

FIGURE 3-19 A key influencer tile in

Power BI

Tables

In addition to the many types of

charts and graphs available in Power
BI, it is possible to include raw data in
a dashboard or report in the form of a
table, as shown in Figure 3-20.

FIGURE 3-20 A table in Power BI

Describe types of filters

Filters are a means by which Power BI

designers and consumers can specify
what data is displayed in reports (but
not in dashboards, which do not
support filtering). For example, if a
data set contains company financial
information for 10 years, the report
designer can create a filter that allows
consumers to select specific years to
be displayed in the report
visualizations.
Any means by which data is
categorized in a data set can be used
as a filter. If a company has five
branch locations, as long as the data
set specifies a branch office for each
data point, the report designer can use
that information as a filter that allows
consumers to select the branch
office(s) to display in a report.

There are four types of filters that

designers can create in a report:

■ Report—Applies to all the pages in the report

■ Page—Applies to all the tiles on the current report page

■ Visual—Applies to a single tile on a report page

■ Drillthrough—Provides access to additional detail within a specific tile

Power BI reports support two means

of selecting the data displayed in
them: slicers and filters, as shown in
Figure 3-21. A slicer is a type of
visualization that functions as a
filtering mechanism consisting of a
list of check boxes like those of the
Executive slicer shown on the left side
of the figure. Consumers can select
any combination of check boxes to
specify which executives should be
represented in the report.

FIGURE 3-21 Slicers and filters in a

Power BI report

The Filters pane, on the right side of

the figure, contains the filters created
by the report designer and the default
filter values the designer specified.
For example, there is a Year filter for
which the designer selected the value
2014 as the default. However, the data
set contains data for other years,
which the consumer can display by
expanding the Year filter, as shown in
Figure 3-22, and then selecting any or
all of the other Year check boxes.

FIGURE 3-22 Power BI report with

Year filter expanded

Power BI filters use basic filtering by

default, but consumers can switch to
an Advanced filtering option, shown
in Figure 3-23, which allows the use of
Boolean operators to create more
complex filter behaviors.

FIGURE 3-23 Power BI report with

the Year filter configured to use
Advanced filtering

When a consumer modifies the filters

to display different information in a
report, Power BI saves the changes
made in that consumer’s account only.
When the consumer opens the same
report again, even on another device,
the changes appear as they were
saved. The consumer can then use the
Reset button at the upper right of the
workspace to return all the filters to
their default settings.

Note Filter Modifications

Consumers can modify the

settings of a report’s existing
filters for use in the current or
future sessions, but they
cannot create new filters or
delete existing ones. Filter
 setting modifications apply
only to that consumer; they do
not modify the appearance of
the report to other consumers,
and as always with Power BI,
they do not modify the original
data sources in any way.

In the Editing view used by report

designers, the Filters pane contains
three sections, as shown in Figure 3-
24, which are labeled as follows:

FIGURE 3-24 The Editing view of a

Power BI report with the Filters pane

■ Filters on this visual

■ Filters on this page

■ Filters on all pages

The designer can drag data fields from

the Fields pane to each section and
then configure the filter for each field
with the default settings that will
appear to consumers.

Exam Tip

Power BI has introduced a new

design for the Filters pane as of
April 2020. Newly created
dashboards and reports use the
new design automatically. Existing
dashboards and reports appear
with the old design, in which the
Filters controls appear in the
Visualizations pane and provide
the designer with the opportunity
to upgrade to the new design. In
the new design, a separate Filters
pane adds new functionality,
including the ability to format the
 Filters pane to match the report,
hide all or part of the Filters pane
from consumers, and lock specific
filters so that consumers cannot
modify them.

Describe the Power BI Desktop Reports,

Data, and Model tabs

The Power BI service interface, shown

in Figure 3-25, has a menu on the left
side of the workspace that provides
the primary means for users to
navigate around the site. The
collapsed menu icon (often called the
hamburger button) at the top of the
menu toggles between the full menu
and a narrow button bar that clears
more room for the workspace.

FIGURE 3-25 Home tab of the

Power BI service interface

The tabs on the menu bar provide

users with access to the various parts
of the interface, as follows:

■ Home—Displays tiles providing access to the user’s favorite, frequently

accessed, and recently accessed Power BI elements; the user’s workspaces
and apps; elements that have been shared with the user; and
recommended apps

■ Favorites—Displays tiles providing access to the Power BI elements

that the user has designated as favorites

■ Recent—Displays a list of Power BI elements that the user has

accessed recently, as shown in Figure 3-26

FIGURE 3-26 Recent tab of the Power BI service interface

■ Apps—Displays tiles providing access to the apps the user has added to
the interface

■ Shared with me—Displays a list of reports and dashboards shared

 with the current user, divided into categories by the sharing user

■ Workspaces—Displays a list of the workspaces created by the user

■ My workspace—Displays a list of the elements in the user’s current

workspace, including dashboards, reports, apps, data sets, and local data
sources

■ Get data—Appearing at the bottom of the pane, displays the Get Data
tab, with tiles that allow the user to discover and create content using
files, databases, online services, and apps published by other users

In Power BI Desktop, when a user

opens a file (or creates a new one), the
navigation pane on the left contains
the following tabs:

■ Report—Displays the pages of the current report file and the

Visualizations and Filters panes, which developers use to create and
modify those pages

■ Data—Displays the contents of the document’s data sources and the

controls for adding measures and transformations

■ Model—In a report with multiple data sources, displays the

relationships among the selected tables

The Report view in Power BI Desktop,

shown in Figure 3-27, is similar to the
workspace edit view in the Power BI
service, with the Fields,
Visualizations, and Filters panes on
the right side of the screen, each of
which the user can collapse
independently for more workspace.
However, Power BI Desktop has a
ribbon at the top of the screen, much
like an Office application, rather than
the button bar found in the service.

FIGURE 3-27 Power BI Desktop

Report view

Describe uses for custom visuals including

charts or controls

Power BI includes a large selection of

visualizations, but it is also possible
for organizations and users to create
their own custom visualizations and
share them within the organization or
with the outside Power BI community.
Custom visualizations can be cosmetic
variants on the appearance of built-in
Power BI visualizations, such as the
addition of a company name or logo,
or they can fulfill data display or
integration requirements that are
specific to the organization. In the
Power BI service interface, selecting
Get more visuals in the Visualizations
pane provides access to the Power BI
Visuals screen, as shown in Figure 3-
28.

FIGURE 3-28 The Power BI Visuals

screen

Note Custom Visuals in Power BI Desktop

In Power BI Desktop, the Get

more visuals icon is labeled
Import a custom visual.

The Power BI visuals screen has two

tabs:

■ AppSource—Contains Power BI visuals available from the Microsoft

AppSource store for business applications

■ My organization—Contains custom Power BI visuals uploaded by the

organization’s administrators

The AppSource store contains

hundreds of Power BI visualizations,
including variations on the chart types
included in Power BI as well as new
chart types and controls for
visualizing data, as shown in Figure 3-
29.

​
FIGURE 3-29 Chord chart

The My organization tab contains

visuals that are exclusive to the
organization, such as those that
contain company branding or other
product-specific features. Before users
can access them, visuals on this tab
must be uploaded to the service by a
Power BI administrator using the Add
Visual dialog box in the Power BI
admin portal, as shown in Figure 3-
30.

FIGURE 3-30 The Add Visual dialog

box in the Power BI admin portal

Creating custom visuals is somewhat

more complicated than creating
Power BI reports and dashboards and
can require some coding. Microsoft
has made the code for their visuals
and the necessary development tools
freely available on its GitHub
repository site. To create a custom
visual, the developer must set up the
correct environment by installing the
Node.js tool and the pbiviz package
and then by creating a certificate.
Then, the developer uses the pbiviz
tool to create a custom visual project.

Need More Review? Creating Custom Visuals

 For more information on the
process of creating custom
visuals for Power BI, see
https://docs.microsoft.com/en
-us/power-
bi/developer/visuals/custom-
visual-develop-tutorial. After
completing the development
process, the result is a file with
a .pbiviz extension that an
administrator can add to the
My organization tab. It is also
possible to submit a custom
visual to the AppSource site
for distribution on the
internet. An optional part of
this process is for Microsoft to
certify the custom visual to
make sure that its code is
secure and that it does not
access any external resources,
such as commercial libraries
or outside services.

Compare and contrast dashboards and

workspaces

As noted in Chapter 1, “Describe the

business value of Power Platform,”
Power BI supports three types of
distributable content: reports,
dashboards, and apps. The report is
the basic content unit, a multipage
document that developers can use to
publish large amounts of data in
various formats. From a report, the
developer can create dashboards,
which are limited to a single page and
consist of visual elements extracted
from a report. An app is a means of
packaging Power BI content from
various sources for distribution as a
freestanding unit.

When a user registers a Power BI

account, the service creates a
workspace for that user. A workspace
is a private area of the service in
which a user can work on their
content prior to sharing it. A
workspace can contain multiple
Power BI elements, including data
sets and Excel workbooks, as well as
dashboards and reports, as shown in
Figure 3-31.

FIGURE 3-31 A default workspace in

the Power BI service

When the content is ready, the

developer can then share individual
elements or use the workspace as a
container to create an app from its
entire contents. Although it is possible
for single developers to create Power
BI dashboards and reports in their
individual workspaces and then share
them with consumers all over the
network, Power BI can also be a
collaborative development
environment.

Users can create multiple workspaces

in addition to the default one and
provide other users with access to
them. Using a shared workspace, a
team of developers can work together
to create Power BI content and keep it
private until it is ready to share with
consumers.

Power BI administrators control the

ability to create new workspaces using
the interface shown in Figure 3-32,
found on the Tenant settings page in
the Power BI admin portal.
Administrators can grant the
permission to everyone, to specific
groups, or to everyone except specific
groups.
 ​

FIGURE 3-32 The Workspace

settings controls in the Power BI
admin portal

Power BI supports two types of

workspaces:

■ Classic workspaces—Use an automatically created Office 365 group to

control access to the space

■ New workspaces—Have four workspace roles that administrators use

to control access, as follows:

■ Admin—Provides all capabilities, including the ability to assign and

revoke workspace roles, including other admins

■ Member—Includes all contributor permissions; provides the ability

to publish and share apps and add members of the same or lesser
roles

■ Contributor—Allows users to create, edit, and delete workspace

content and publish reports to the workspace

■ Viewer—Allows users to view and interact with workspace content

and read the data in workspace data sets

Exam Tip

As of mid-2020, the new

workspace is the default type
created in the Power BI service,
although it is still possible to
create classic workspaces.
Candidates preparing for the PL-
900 exam should be aware that
many Power BI resources might
not be updated to reflect the new
workspace type and its default
status.

Creating a new workspace

The Workspaces tab in the Power BI

service interface includes a Create a
workspace button that opens the
dialog box shown in Figure 3-33. As
noted, the new workspace is now the
default, so the process of creating a
workspace does not automatically
create an Office 365 group.

FIGURE 3-33 The new Create a

workspace dialog box in the Power BI
service

To control access to a new workspace

after it is created, click the Access
button to open the Access dialog box,
as shown in Figure 3-34, in which you
specify users and the workspace roles
assigned to them.

FIGURE 3-34 The workspace Access

dialog box in the Power BI service

Creating a classic workspace

To create a classic workspace instead,

the user must click the Revert to
classic link in the Create a workspace
dialog box to open the alternative
interface shown in Figure 3-35.
Creating a classic workspace creates
an Office 365 group. In this dialog
box, the user specifies whether the
workspace should be private or public
and whether members of the Office
365 group should have read/write or
read-only access to the contents of the
workspace.

FIGURE 3-35 The classic Create a

workspace dialog box in the Power BI
service

Compare and contrast Power BI Desktop

and Power BI service

The Power BI service is the cloud-

based environment that both
developers and consumers use to
create and access dashboards, reports,
and other content. Power BI Desktop
is a Windows application that
provides more advanced data
modeling and report development
capabilities.

Because it is cloud based, the Power

BI service is accessible to all users, on
almost any device. Whatever tool
developers use to create reports or
dashboards, they publish them to the
Power BI service so that consumers
can access them freely. The Power BI
service also allows developers to
collaborate by providing them with
access to documents stored in the
cloud.

The Power BI service has a Reading

view for consumers and an Edit view
for developers. The Reading view
displays the Pages and Filters pane,
whereas switching to the Edit view
moves the pages tabs to the bottom of
the screen and adds the Visualizations
and Fields panes on the right side, as
shown in Figure 3-36.

FIGURE 3-36 Power BI service in

Edit view

Power BI Desktop is intended as a

development and editing
environment; consumers cannot use it
to access shared content. It also does
not support collaboration in the way
that the service does. There are no
workspaces in Power BI Desktop;
instead, users open individual content
files that use a format with a .pbix
extension.

The Power BI service and Desktop

tools have some basic functions in
common, but each has some
capabilities that the other lacks, as
shown in the Venn diagram in Figure
3-37. The primary strength of Power
BI Desktop, when compared to the
service, is the ability to access
multiple data sources and model the
data using the Power Query Editor
tool.
 ​

FIGURE 3-37 Power BI service and

Desktop capabilities

SKILL 3.2: CONNECT TO AND

CONSUME DATA

The first step in creating Power BI

content is to access the data that the
developer intends to illustrate using
the charts and other types of
visualizations that Power BI provides.
Doing so calls for the developer to
establish a connection to any of the
data sources that Power BI supports
and to select specific data provided by
that source. Power BI Desktop allows
developers to connect to multiple data
sources and model the data into the
form needed to tell an appropriate
story in the Power BI report.

This skill covers how to:

■ Combine multiple data sources

■ Clean and transform data

■ Describe and implement aggregate functions

■ Identify available types of data sources including Microsoft Excel

■ Describe use cases for shared data sets and template apps and how
to consume each

Combine multiple data sources

The Power BI service allows

developers to connect to any one of
hundreds of data sources. However, in
Power BI Desktop, it is possible to
connect to multiple data sources at
once and combine the information
from them into a single data model.

As noted earlier in this chapter,

connecting to a data source is the first
step in creating a Power BI report.
When you create a new file in Power
BI Desktop, the startup screen
includes a Get data button that starts
the process of connecting to a data
source by displaying the Get Data
screen shown in Figure 3-38.

FIGURE 3-38 The Get Data screen

in Power BI Desktop

The developer can choose from

hundreds of data sources, which
generate proper screens for the
submission of credentials. For
example, to access data on a webpage,
Power BI Desktop generates an Access
Web content dialog box, as shown in
Figure 3-39. Here, the developer can
choose to access the webpage
anonymously or specify one of the
standard web authentication
protocols.

FIGURE 3-39 The Access Web

content screen from Power BI
Desktop

After the developer has authenticated

to the data source (if necessary),
Power BI Desktop evaluates the data
found at the source and displays the
Navigator screen, as shown in Figure
3-40, containing all the tables it has
found. Selecting a table and clicking
Load adds the data to the Fields pane
in the Report view.

FIGURE 3-40 The Navigator screen

in Power BI Desktop

At this point, the developer can repeat

the process to access one or more
additional sources and add them to
the Report view. In the Home tab in
Power BI Desktop, the developer can
select one of the icons in the Data
group or select Transform data to
open the Power Query Editor tool and
select New Source.

Once the developer combines the

queries, the data from the additional
sources is added to the Fields pane, as
shown in Figure 3-41. The developer
can then proceed to use the data from
the various sources to create
visualizations for the report, but it is
more likely that the data will require
some modeling first. Developers do
this using the Power Query Editor tool
in Power BI Desktop.
 ​

FIGURE 3-41 The Fields pane in

Power BI Desktop with two data
sources

Clean and transform data

Whether a Power BI content

developer accesses one data source or
many, it is possible that the data
might need modeling before it can be
used effectively in a report. Data
modeling—also called shaping or
transforming data—is a term that can
refer to a variety of tasks, including
the following:

■ Modifying data types

■ Removing rows or columns

■ Renaming tables, rows, or columns

■ Splitting columns

The purpose of data modeling is to

select and arrange the data accessed
from the source so that it suits the
visualization the developer intends to
create. As always, modeling the data
in Power BI does not change the
original data in the source, so
splitting, removing, and renaming
rows and columns has no effect on the
original data.

Modifying data types

One example of a data transformation
is to modify the data type of a column.
When a developer accesses a webpage
as a data source, the resulting table
might contain numerical values that
Power BI Desktop sees as text. For
example, the Overall rank column in
Figure 3-42 is labeled as text (as
shown by the ABC tag in the column
header). Even though the values
appear to be numbers, the Power
Query Editor reads them as text and
cannot use them in mathematical
calculations.

FIGURE 3-42 Text column in Power

Query Editor

By right-clicking the Overall rank

column and selecting Change Type
from the context menu, or by selecting
the Data type drop-down list in the
ribbon’s Transform group, the
developer can choose Whole Number
to convert the column to numerical
values that the Power Query Editor
can use in mathematical operations
(as shown by the 123 tag in the
column header in Figure 3-43).

FIGURE 3-43 Whole number

column in Power Query Editor

After the developer changes the data

type, that modification appears in the
Query Settings pane in the Applied
Steps box as Changed Type. To undo
the change, the developer can simply
delete the Changed Type
transformation. Each transformation
a developer applies to the data is
added to the Applied Steps list for
later manipulation, if necessary.

Need More Review? Using Power Query Editor

For more information on

using the Power Query Editor,
see
https://docs.microsoft.com/en
-us/power-query.

Removing rows and columns

When combining data from different

sources, it is common for developers
not to need everything that Power BI
Desktop obtains from each source.
For example, the Ranking of best and
worst states for retirement webpage
accessed in the previous section
includes a column containing the
names of the states. However, a
developer might want to use the two-
letter state abbreviations instead. To
do this, the developer can access
another data source that contains
columns specifying the state names
and their abbreviations. However,
that data source might include other
information as well.

For example, the data source shown in

Figure 3-44 includes a column
containing the full names of the
states, as well as one containing the
equivalent ANSI values, which are the
standard two-letter state
abbreviations. However, there are 11
columns in total, of which the
developer needs only two. It is
therefore possible to select the
unneeded columns and select Manage
Columns > Remove Columns in the
ribbon to delete them.

FIGURE 3-44 State abbreviations in

a second data source

Renaming elements

Depending on the configuration of the

data as it appeared in the source, it
might be necessary for a developer to
click the Use first row as headers
command in the ribbon’s Transform
group to create column headers. It is
also possible for the developer to
right-click a column and rename the
header to accommodate the needs of
the other source to which the
developer will merge or append the
data.

Combining queries

Modeling data is essentially a matter

of applying one or more queries to it.
Power BI Desktop therefore refers to
the modeled data from a source as a
query. After the developer has
modeled the data from multiple
sources, it is possible to combine the
queries in two ways:

■ Merge—Adds columns from one data source to the existing columns

from another source

■ Append—Adds new rows from one data source to the existing rows in
another source

In the previous example, the

developer sought to add the state
abbreviations to the Ranking of best
and worst states for retirement data.
To do this, the developer selects the
target data source and, on the ribbon,
selects Combine > Merge Queries.

In the Merge dialog box, shown in

Figure 3-45, the developer selects the
query to be merged and the columns
to be matched during the process. In
this example, selecting the State and
State Name columns will synchronize
the state abbreviations with the
correct names.

FIGURE 3-45 The Merge dialog box

in Power BI Desktop

Clicking OK in the Merge dialog box

causes the merged data to appear in
the original source, as shown in
Figure 3-46. The entire merged query
appears as a single column with the
word “table” in each cell, indicating
that column contains all the merged
columns in contracted form.

FIGURE 3-46 Power Query Editor

with merged query

Clicking the Expand button at the

right side of the column header
displays the dialog box shown in
Figure 3-47. By selecting or clearing
check boxes, the developer can specify
which expanded columns should
appear in the merged query.
 ​

FIGURE 3-47 Expand dialog box in

Power Query Editor

For this example, the developer

should clear all but the Abbreviation
check box and then click OK. The
Abbreviation column is now merged
into the Ranking of best and worst
states for retirement query, as shown
in Figure 3-48.

FIGURE 3-48 Power Query Editor

with expanded merged query

When the data modeling process is

complete, clicking Close & Apply in
the ribbon’s Close group adds the
table from the Power Query Editor to
the report in Power BI Desktop.

Describe and implement aggregate

functions

Power BI uses the term aggregate to

refer to mathematical functions that it
executes on values obtained from data
sources. When Power BI evaluates
data, it automatically aggregates
certain data types to anticipate the
needs of the developer in creating a
report. For example, when Power BI
imports a table containing sales
figures for a company’s branch offices,
it might aggregate those figures using
the sum function to add up totals for
the product sales categories. Although
Power BI does this automatically, it is
still possible for developers to modify
the automatic aggregations or apply
new aggregations to data as needed.

It is the Value element in a

visualization that is typically
aggregated by Power BI during its
evaluation of the data. For example, in
Figure 3-49, the values represented in
the column chart are taken from the
data source’s Units Sold field.
Hovering the mouse cursor over that
field in the Value well indicates that
the amounts used to create the chart
are sums of the units sold. In the
original source data, each product has
dozens of Units Sold values for each
product, broken down by country.
Power BI has added the values for
each product to arrive at the totals
used for the chart.

FIGURE 3-49 Power BI visualization

with indication of aggregate

If for any reason a developer does not

want to use sums of the units sold to
create the visualization, it is possible
to change the aggregate by right-
clicking the field in the Value well to
display the list of functions shown in
Figure 3-50. For example, selecting
Average instead of Sum causes Power
BI to recalculate the values and
redraw the chart with the averages
instead of the sums. Other aggregates
that Power BI supports include
minimum, maximum, count
(distinct), count, standard deviation,
variance, and median.

FIGURE 3-50 Power BI visualization

with aggregate context menu

It is also possible to aggregate a text

field, but Power BI obviously does not
support mathematical functions such
as sum and average for this purpose.
Only functions such as count, distinct
count, first, and last are applicable.

Identify available types of data sources

including Microsoft Excel

Before Power BI developers can do

any modeling or visualizing, they
must obtain the data they intend to
use. The Power BI service and Power
BI Desktop both provide support for
hundreds of data sources, which they
can access as local files, as databases
within the organization, or as cloud-
based services on the internet,
whether public or private.

The data sources available in the

Power BI service and Power BI
Desktop differ, as does the means of
accessing them. Microsoft is
continually adding support for more
data sources in Power BI, so it is not
uncommon to see sources with beta or
preview tags that are currently in
development and might not be fully
functional.

Power BI service data types

In the Power BI service, you can begin

the process of selecting and
connecting to data sources by clicking
Get Data in the navigation pane on
the left to display the screen shown in
Figure 3-51.

FIGURE 3-51 The Get Data screen in

the Power BI service

The Get Data screen displays four

tiles:

■ My organization—Provides access to apps and organizational content

packs published to the AppSource repository by other users in the
organization

■ Services—Provides access to apps and organizational content packs

published to the AppSource repository by third-party users and
organizations

■ Files—Provides access to data files stored on the local computer or

network, including Excel workbook files, comma-delimited value (CSV)
files, and Power BI Desktop (PBIX) files

■ Databases—Provides access to cloud-based databases, such as Azure

SQL Database and SQL Server Analysis Services, and on-premises
databases

Some of the data sources listed in the

Power BI service require developers to
install and run Power BI desktop, as
shown in Figure 3-52, which offers a
more comprehensive set of sources.

FIGURE 3-52 The Create new

content screen in the Power BI service

Power BI Desktop data types

Power BI Desktop includes a larger set

of data source connections from
which developers can choose and a
tabbed interface that provides simpler
access to them:

■ All—Contains a list of all the connections found on the other tabs

■ File—Contains connectors for Excel workbooks, text files, SharePoint

folders, PDFs, and other standard file formats, as shown in Figure 3-53
 ​

FIGURE 3-53 The File tab in Power BI Desktop’s Get Data dialog box

■ Database—Contains connectors for many of the standard commercial

database formats, including SQL, Access, Oracle, IBM Informix, Sybase,
and SAP, as shown in Figure 3-54

FIGURE 3-54 The Database tab in Power BI Desktop’s Get Data dialog
box

■ Power Platform—Contains connectors for data sources from other

Power Platform elements, including Power BI data sets, Power BI
dataflows, Common Data Service, and Power Platform dataflows

■ Azure—Contains connectors for many Microsoft Azure data storage

solutions, including Azure SQL Database, Azure Blob Storage, Azure
Table Storage, and Azure Data Lake Storage, among others, as shown in
Figure 3-55

FIGURE 3-55 The Azure tab in Power BI Desktop’s Get Data dialog box

■ Online Services—Contains connectors for dozens of internet services,

including SharePoint Online, Exchange Online, Google Analytics, Adobe
Analytics, and many others, as shown in Figure 3-56
 ​

FIGURE 3-56 The Online Services tab in Power BI Desktop’s Get Data
dialog box

■ Other—Contains connectors for various other sources, including

websites, SharePoint lists, Active Directory, Spark, and Python scripts,
among others, as shown in Figure 3-57

FIGURE 3-57 The Other tab in Power BI Desktop’s Get Data dialog box

Depending on the nature of the

connection, selecting one of the data
sources generates additional screens
with controls for making further file
selections or supplying authentication
credentials. When you create a data
set, the selections and credentials you
specified with the data source are
saved with it so that it will not be
necessary to enter them again.

Describe use cases for shared data sets

and template apps and how to consume
each

Shared data sets and template apps

are ways for Power BI users to
function as content developers
without a great deal of experience
manipulating data or Power BI
constructions.
Using shared data sets

Obtaining and modeling data are the

first—and arguably the most
important—parts of creating a report
or dashboard in Power BI. These steps
can be complicated and require a lot
of time and effort, so Power BI makes
it possible to share data sets with
other users. This way, developers do
not always need to have a complete
understanding of the data they use to
create reports, dashboards, and apps.
They can access data that has already
been transformed and modeled into a
useful state.

Data set sharing is an important

element of the new workspace model
in Power BI. Data sets saved to a new
workspace are automatically shared
with other new workspaces. For
example, Figure 3-58 displays the
Datasets + dataflows tab of a new
workspace. The Customer Profitability
Sample, Financial Sample, and
Human Resources Sample data sets
are stored in that workspace;
however, the Retail Analysis Sample
data set is stored in another new
workspace and yet it appears in this
list.

FIGURE 3-58 The Datasets +

dataflows tab of a new workspace in
the Power BI service

This figure also includes data sets that

have been endorsed to indicate that
they are of particularly high quality
and suitable for use by other
developers. Data sets with the blue
Promoted tag are endorsed by their
creators. The green Certified tag
appears on data sets that their
creators have submitted for
certification by a group of expert users
selected by the organization’s Power
BI administrators.

It is also possible for developers to

apply permissions to data sets to
regulate what other users can do with
them. When you select Manage
permissions from the context menu of
a data set, its Manage access page
appears, as shown in Figure 3-59.

FIGURE 3-59 The Manage access

page for a data set in the Power BI
service

From this page, the owner of a data

set can add users and assign them the
following permissions:

■ Read—Allows recipients of the permission to reshare the element

■ Build—Allows recipients of the permission to build new content from

the element

Using template apps

Power BI template apps are sets of

prepackaged reports and dashboards
that users can download from the
AppSource repository and connect to
their own live data sources.
Developers can create template apps
and distribute them within their
organizations or submit them for
publication on AppSource.

On the Apps page in the Power BI

service, clicking the Get apps button
opens the AppSource interface,
enabling the user to browse through
the many templates available. After
selecting and installing a template,
Power BI creates a new workspace for
it, and a Get started with your new
app screen appears, as shown in
Figure 3-60.

FIGURE 3-60 The Get started with

your new app screen in the Power BI
service

The Get started with your new app

screen provides three ways to utilize
the template app:

■ Connect—Allows the users to connect the app to their own data

sources, to create fully operational reports and/or dashboards using
current data

■ Explore—Provides access to the reports and/or dashboards in the app

using sample data included with the template

■ Customize—Opens the workspace created during the installation of the

template, enabling the user to modify the reports and/or dashboards or
just examine their construction

SKILL 3.3: BUILD A BASIC

DASHBOARD USING POWER BI

A dashboard is a single-page Power BI

document, like the one shown in
Figure 3-61, that presents consumers
with a selection of tiles containing
highlights from one or more reports.
The object of a dashboard is to tell a
story relatively concisely, in relation
to a report. It is assumed that if the
consumers require more information,
they can simply look at the report(s)
from which the dashboard tiles came.

FIGURE 3-61 Sample Power BI

dashboard

This skill covers how to:

■ Design a Power BI dashboard

■ Design data layout and mapping

 ■ Publish and share reports and dashboards

Design a Power BI dashboard

A dashboard is a single page

composed of tiles, rectangular
placeholders containing visualizations
taken from existing reports and data
sets that update in real time.
Dashboards are essentially gateways
to the reports and data sets from
which the tiles are taken. When
consumers click a tile on a dashboard,
they are taken to the report that is the
source for the tile.

There are advantages to creating

dashboards, rather than having
consumers just access the reports
from which they were sourced
themselves. A dashboard is a single
page, whereas a report can have many
pages. Therefore, a well-designed
dashboard contains only the
information that is essential to the
story that the developer wants to tell.
Dashboards can also take their tiles
from multiple dashboards and data
sets. This allows a developer to use
resources from several places to create
a composite picture of a situation or
process.

Although developers can create

reports and data sets in either the
Power BI service or Power BI
Desktop, they can only create
dashboards in the Power BI service.
Therefore, any reports and data sets
created and saved in Power BI
Desktop must be published to the
service before developers can use
elements from them in dashboards.

The process of creating a dashboard

begins with the creation of a report by
connecting to a data source, modeling
the data, and creating visualizations.
There are then several ways to create
a dashboard, but the simplest is to pin
visualizations from the report to a
new, empty dashboard, as in the
following procedure.

1. Open a report in the Power BI service in Edit view and select a

visualization. A toolbar appears in the upper-right corner, as shown in
Figure 3-62.

FIGURE 3-62 A Power BI report visualization with toolbar

2. Click the Push pin icon in the toolbar to open the Pin to dashboard
dialog box, as shown in Figure 3-63.

FIGURE 3-63 The Power BI Pin to dashboard dialog box

3. Select the New dashboard radio button, specify a name in the

Dashboard name field, and click Pin. The new dashboard is created in
the default workspace, and a Pinned to dashboard message appears.

4. Click Go to dashboard. The newly created dashboard appears with the

selected visualization on it, as shown in Figure 3-64.

FIGURE 3-64 A newly created

dashboard with a single visualization

After Power BI has created the new

dashboard, the developer can pin
additional visualizations to it, this
time selecting the Existing dashboard
option in the Pin to dashboard dialog
box. The additional visualizations can
come from the same report as the first
one or from different reports.

Note Creating a Live Page

If a developer wants to create a

dashboard that consists of an
 entire page from a report, it is
possible to do so without
pinning each visualization
individually by clicking the
More options button on the
page’s toolbar and selecting
Pin a live Page from the
context menu to generate a Pin
to dashboard dialog box like
the one shown earlier.

It is also possible to add tiles

containing media content and other
material directly to a dashboard by
selecting Add tile from the More
Options menu to display the Add tile
dialog box shown in Figure 3-65.

FIGURE 3-65 The dashboard Add

tile dialog box in the Power BI service

Design data layout and mapping

The combination of the pinned

visualizations from reports and the
additional material available through
the Add tile dialog box allow
developers to design dashboards that
tell a specific story to the consumers
and provide them with access to more
detailed information in the reports
themselves. Deciding what
information needs to appear on a
dashboard and how that information
should be visualized is an important
part of the dashboard design and
creation process.

Designing for screen size

Because a dashboard is only a single

page, developers must consider the
size of the screen that consumers will
be using to view it. Dashboards are
scrollable, both vertically and
horizontally, so it is possible to create
a page that is longer or wider than the
actual screen, but developers typically
should try to avoid overly large pages
for the convenience of consumers.
This is especially true when
consumers will be using mobile
devices with small screens.

After the developer has pinned all the

desired tiles to the dashboard, it is
possible to move them around, resize
them, and add titles and subtitles to
create a usable configuration.

The choice of display is up to the

consumer, but developers might want
to consider sizing dashboards to
accommodate full-screen mode, with
which consumers can eliminate all the
surrounding frames and navigation
panes to display only the dashboard
itself.

When working with a dashboard in

Power BI service, developers can
switch between the standard web view
and a mobile view, as shown in Figure
3-66. The mobile view arranges the
titles vertically on a scrollable
interface so that text is readable on a
smaller screen.
 ​

FIGURE 3-66 Mobile view of a

dashboard in the Power BI service

Emphasizing importance

The other design consideration that

developers should observe is the
relative importance of the
visualizations being displayed. For
example, in the detail from the sample
dashboard shown in Figure 3-67, the
table lists the available beds and the
occupancy rate for each of seven
facilities, with totals at the bottom.
However, to provide the consumer
with an immediate overview of the
data, the totals for all the facilities
combined are also displayed above the
table in card tiles, using much larger
type.

FIGURE 3-67 Dashboard table tile

with significant statistics displayed as
card tiles
The decision as to what data is most
important is, of course, particular to
the subject and to the audience for the
dashboard. New developers might
find that the dashboard design
process requires some trial and error,
both to accommodate the screen size
and to select the tiles from the report
that are most important to the
consumers. The process might even
involve modifications to the report
from which the tiles are taken. For
example, an elaborate chart
visualization might be appropriate for
the report, but a developer might find
it necessary to create some smaller
card tiles isolating the most
significant statistics from the chart
and pin those to the dashboard to save
space, rather than including the entire
chart.

Publish and share reports and dashboards

After creating a report or dashboard

in the Power BI service, developers
can share it with selected users. These
users then become consumers of the
content, meaning that they can view
the material and interact with it (by
adding comments, for example), but
they cannot edit it.

Exam Tip

To share content, both the

developer and the consumer must
have Power BI Pro licenses or be
working in a Power BI Premium
workspace. Candidates for the PL-
900 exam can access the free
version of Power BI, but to work
with the sharing features, they can
obtain a trial version of Power BI
Pro from Microsoft.

When you select a dashboard or

report in a service workspace and
click the Share icon, the Share
dashboard or the Share report dialog
box appears, like the one shown in
Figure 3-68.

FIGURE 3-68 The Share dashboard

dialog box in the Power BI service

After specifying the addresses of the

users with whom the developers want
to share the content, they can select or
deselect the following options:

■ Allow recipients to share your dashboard/report—Allows recipients

to reshare the content with other users

■ Allow recipients to build new content using the underlying datasets—

Allows recipients to utilize the data sets with which the report or
dashboard was created, using the developer’s credentials if necessary

■ Send an email notification to recipients—Generates an email

containing a link to the report or dashboard and sends it to each recipient

For developers working in Power BI

Desktop, their completed content is
not accessible to consumers until they
publish it to the Power BI service, as
in the following procedure:

1. With the completed content file open in Power BI Desktop, click the
Publish button on the ribbon’s Home tab or select File > Publish >
Publish to Power BI. If the file has changes that have not been saved, a
prompt appears to save it.

2. If the developer is not signed on to the Power BI service, a sign-on

interface appears. After the sign-on is complete, the Publish to Power
BI dialog box appears, as shown in Figure 3-69.

​
 FIGURE 3-69 The Publish to Power BI dialog box in Power
BI Desktop

3. Select one of the available workspaces listed in the dialog box and click
Select.

4. When the publication process is completed, a Success message box

appears, containing a link to the published file in the Power BI service,
as shown in Figure 3-70.

FIGURE 3-70 Publishing to Power

BI Success message box in Power BI
Desktop

CHAPTER SUMMARY
■ Visualizations are the formats designers can use to display data in a
Power BI dashboard or report. Power BI provides a large selection of
visualizations to choose from, including various types of charts, tables,
maps, gauges, apps, and cards.

■ Filters are a means by which Power BI designers and consumers can

specify what data is displayed in reports.

■ The Power BI service interface has a menu on the left side of the
workspace that provides the primary means for users to navigate around
the site.

■ With Power BI, it is possible for organizations and users to create their
own custom visualizations and share them within the organization or
with the outside Power BI community.

■ When a user registers a Power BI account, the service creates a

workspace for that user. A workspace is a private area of the service in
which users can work on their content prior to sharing it.

■ The Power BI service is the cloud-based environment that both

developers and consumers use to create and access dashboards, reports,
and other content. Power BI Desktop is a Windows application that
provides more advanced data modeling and report development
capabilities.

■ The Power BI service allows developers to connect to any one of

hundreds of data sources. However, in Power BI Desktop, it is possible to
connect to multiple data sources at once and combine the information
from them into a single data model.

■ Data modeling is a term that can refer to a variety of tasks, including

modifying data types; removing rows or columns; and renaming tables,
rows, or columns.

■ Power BI uses the term aggregate to refer to mathematical functions

that it executes on values obtained from data sources.

■ Power BI makes it possible to share data sets with other users, so

developers do not always need to have a complete understanding of the
data they use to create reports, dashboards, and apps.

■ A dashboard is a single page composed of tiles, rectangular

placeholders containing visualizations taken from existing reports and
data sets that update in real time.

■ Because a dashboard is only a single page, developers must consider

the size of the screen that consumers will be using to view it.

■ After creating a report or dashboard in the Power BI service,

developers can share it with selected users.

■ For developers working in Power BI Desktop, their completed content

is not accessible to consumers until they publish it to the Power BI
service.

THOUGHT EXPERIMENT

In this thought experiment,

demonstrate your skills and
knowledge of the topics covered in
this chapter. You can find answers to
this thought experiment in the next
section.

Ralph is new to Power BI, and he

wants to create a dashboard that
compares the number of COVID-19
cases in each of a selected group of
East Coast U.S. states on a particular
day. He has found a website with a
table containing the necessary data
for all 50 states, which is updated
daily. After studying Power BI for a
while and planning the process of
creating a dashboard, Ralph expects
to perform the following tasks:

1. 1. Create a data set from the COVID-19 data on the website.

2. 2. Create a report with table and column chart visualizations of the

data for the 50 states.

3. 3. Create a dashboard and pin the table and column chart

visualizations from the report to it.

4. 4. Use filters to restrict the data in the two visualizations to the

desired East Coast states.

5. 5. Share the dashboard with selected users on the network.

However, Ralph is somewhat

confused about whether to use the
Power BI service or Power BI Desktop
to perform these tasks. For each of
these tasks, specify whether Ralph can
use the Power BI service only, Power
BI Desktop only, or either the Power
BI service or Power BI Desktop.
Explain your answers by specifying
any additional tasks that Ralph might
have to perform.

THOUGHT EXPERIMENT
ANSWERS
1. 1. To create a data set from the website, Ralph must use Power BI
Desktop only.

2. 2. To create a report with the desired visualizations, Ralph can

conceivably use either the Power BI service or Power BI Desktop. To
use the Power BI service for this task, however, Ralph must first save
the data as a PBIX file in Power BI Desktop and publish the file to a
workspace in the Power BI service.

3. 3. To create a dashboard, Ralph must use the Power BI service. If he

has not done so already, he must save the report containing the data
set he created in Power BI Desktop as a PBIX file and publish it to his
workspace in the Power BI service.

4. 4. To use filters to limit the states displayed in the visualizations,

Ralph can conceivably use either the Power BI service or Power BI
Desktop to edit the report. If he does this in the Power BI service, the
filters will be applied automatically to the dashboard. If he wants to do
this in Power BI Desktop, however, he will have to publish the filtered
report to the Power BI service again.
5. 5. To share the dashboard, Ralph must use the Power BI service.
Chapter 4

Demonstrate the
capabilities of Power Apps
As with the other Power Platform
tools, Power Apps is designed for
citizen developers with little or no
coding experience. The tool allows
users to create cloud-based apps that
range in capability from simple
information-gathering tools to
internet-facing data access solutions.
Power Apps can access hundreds of
public and private data sources, as
well as Power Platform’s own
Common Data Service. Unlike Power
BI, which is based primarily on read-
only access to data sources, Power
Apps can be fully interactive, building
up databases and replacing paper-
based processes with digital ones.

The fundamental philosophy behind

Power Apps is to provide
organizations with a development
paradigm that allows manual business
processes to be realized as digital,
automated processes without the need
for an extensive development budget
or a large team of development
engineers.

Many large organizations have

hundreds or thousands of manual
procedures in place, and realizing
them as traditionally developed
applications could require a huge,
costly, and lengthy IT expansion. With
a no-code development environment
such as Power Apps, the personnel
who will actually be using the apps
can be responsible for designing and
building them. Instead of outside
developers having to familiarize
themselves with the users’ needs, the
users can decide what they need and
when they need it.
Skills covered in this chapter:

■ 4.1: Identify common Power Apps components

■ 4.2: Build a basic canvas app

■ 4.3: Describe Power Apps portals

■ 4.4: Build a basic model-driven app

SKILL 4.1: IDENTIFY COMMON

POWER APPS COMPONENTS

Power Apps allows developers to

create three types of applications:
canvas apps, model apps, and portal
apps. The processes for creating these
apps are similar, but their functions
and the design properties available to
the developer are different.

This skill covers how to:

■ Describe differences between canvas apps and model-driven apps

■ Describe portal apps

■ Identify and describe types of reusable components including

canvas component libraries and Power Apps Component Framework
(PCF) components

■ Describe use cases for formulas

Describe the differences between canvas

apps and model-driven apps

Power Apps supports two types of

internal applications: canvas apps and
model-driven apps. The two types are
similar in many ways, but they differ
primarily in the flexibility of their
interfaces and in the nature of the
data sources they use.

Canvas apps

Canvas apps are the original

application type supported by the
Power Apps tool when it was released
in 2016. Rather than write code,
developers can create canvas apps by
dragging and dropping elements onto
a blank canvas in Power Apps Studio,
in much the same way as PowerPoint
users design slides. The developers
then link the app to one or more data
sources using the many connectors
supplied with Power Platform and
expressions that are similar to those
used in Excel.
There are three ways to create a
canvas app, as shown in Figure 4-1: by
starting from a blank canvas, by
starting with data from the Common
Data Service or through one of the
other Power Platform connectors, or
by starting with one of the many
templates included in the Power Apps
portal.

FIGURE 4-1 The Create page of the

Power Apps portal

In the sample help desk canvas app

shown in Figure 4-2, the center pane
displays the Login screen, the first one
that users and admins will see when
they open the app. The right pane
contains controls for manipulating the
appearance of the Login screen, and
the left pane contains an expandable
list of the various screens in the app
and the components the developer has
placed on them.

FIGURE 4-2 A canvas app in the

Power App portal

This sample app has several other

screens, some of which are shown in
Figure 4-3. Developers can modify the
screens as needed, both by adding or
removing controls or by altering the
colors and other cosmetic properties.

FIGURE 4-3 Three additional

screens from the Power Apps sample
help desk app

Canvas apps (unlike model-driven

apps) provide the developer with
complete freedom over the creation of
the application interface. In addition
to cosmetic properties, developers can
configure canvas apps to display data
in different ways, or even create
controls that allow users to sort and
limit the data.

After the app is completed, the

developer can share it in the cloud
with users running desktop browsers
or iOS and Android mobile devices.
One of the other strengths of canvas
apps is their ability to be embedded in
other services, including Power BI
reports, SharePoint sites, and
Microsoft Teams.

The help desk app shown in the

earlier example uses a portrait
orientation, which makes it suitable
for display on mobile devices, such as
smartphones and tablets. When
developers build apps intended for
use on browsers, landscape
orientation is also available.

Note Power Apps Operating System and Browser

Requirements

To run canvas apps, the Power

Apps clients for mobile devices
 require iOS version 12 or later
or Android 7 or later. PCs
require Windows 8.1 or later.
The browsers supported by
Power Apps include Microsoft
Edge, Internet Explorer 11,
Google Chrome, Mozilla
Firefox, and Apple Safari.

Model-driven apps

Compared with canvas apps, model-

driven apps do not provide the same
interface configuration capability.
Instead, the developer begins by using
business functions and business
processes to create a data model in the
Common Data Service and then
selects and configures the
components to be added to the app,
such as forms, views, charts, and
dashboards, in the Add Designer
interface, as shown in Figure 4-4.

FIGURE 4-4 The App Designer

interface in the Power Apps portal

Using the source data and the

components selected by the
developer, the app then uses the
Unified Client Interface (UCI) to
design and create a tile-based display
like the one shown in Figure 4-5. By
rearranging the tiles, developers make
it possible for the app to automatically
adapt itself to the screen
configurations of different device
types. Canvas apps therefore have
more design flexibility, but model-
driven apps support more complex
business logic. In some cases, a
model-driven app can function as the
back end for a canvas app.
 ​

FIGURE 4-5 A model-driven app

Because they rely on the Common

Data Service, model-driven apps have
different licensing requirements than
canvas apps. Microsoft 365
subscribers have the Power
Apps/Power Automate license needed
to create canvas apps using the
standard set of connectors, but to use
premium connectors or the Common
Data Service, which is required for
creating model-driven apps, an
additional Power Apps license is
needed.

Dynamics 365 is itself based on

model-driven apps and the Common
Data Service, so subscribers have the
Power Apps/Power Automate
licensing needed to create their own
model-driven apps and use premium
connectors. For users that do not
subscribe to Microsoft 365 or
Dynamics 365, there are standalone
Power Apps licenses available on a
“per user, per app” or “per app” basis,
which include Power Automate
capabilities. Both license options
provide access to the full set of Power
Apps capabilities, including the
Common Data Service and standard,
premium, and custom connectors.

Exam Tip

Candidates for the PL-900 exam

should be aware that Microsoft
provides time-limited trial
versions of Microsoft 365 and
 Dynamics 365, which include the
full Power Apps and Power
Automate capabilities described
here. A trial version of Power BI
Pro is also available as a separate
product.

Describe portal apps

A portal app is a means of providing

users—both internal and external—
with access to data stored in the
Common Data Service using a
website. Organizations can use portal
apps to provide customers, partners,
and employees with self-service access
to business information that
eliminates the need for many call
center and face-to-face transactions.

Portal apps were at one time a feature

of a Dynamics 365 add-on product,
but Microsoft has now incorporated
them into Power Apps. Users are
limited to creating a single portal app
in an environment. Because the portal
app accesses and stores all of its data
in the Common Data Service, there is
no need or capacity for establishing
connections to outside applications
and services.

Selecting the Portal from blank tile on

the Create screen of the Power Apps
portal prompts the user to confirm the
provisioning of the current
environment with the components
needed to create the portal app. This
can include the Common Data
Service, if not installed already,
appropriate entities and data, and a
starter portal template. After the
provisioning is complete, the portal
app appears on the Apps page.
Opening the portal app displays the
starter page for the website, as shown
in Figure 4-6.
 ​

FIGURE 4-6 Starter page for a

Power Apps portal app

Exam Tip

Candidates for the PL-900 exam

should be aware that Microsoft
and other sources use the word
portal frequently and with many
different definitions. In
computing, the term portal is
usually defined as a webpage that
provides access to other services,
applications, or websites. In the
context of the Power Platform
tools and other Microsoft cloud
services, it is common to refer to
their management and
administration websites as portals.
Be sure to avoid confusing these
applications for the term with the
portal app in Power Apps.

After the portal app has been created,

the developer can then edit the
website as needed by creating new
pages, adding components, and
applying templates, using the
interface shown in Figure 4-7.

FIGURE 4-7 Editing interface for a

portal app
Identify and describe types of reusable
components including canvas component
libraries and Power Apps Component
Framework (PCF) components

Developers working from a blank

canvas can create components that
define the characteristics of the app’s
screen elements. A component can be
a form, a button, a text box, or any
other element. It is possible to create
a button or other screen element
individually, but the advantage of
creating it as a component is that it
becomes reusable on multiple screens.
Components in Power Apps function
in much the same way as styles in
Microsoft Word; they consist of
multiple attributes that users can
apply in one step.

For example, a canvas app might

consist of several screens, each of
which has one or more buttons on it,
and the developer wants all the
buttons to have the same basic
appearance. By creating a component
containing the button characteristics,
such as shape, color, and text size, the
developer can create buttons on each
app screen that all look the same. If,
at a later time, the developer decides
to change the appearance of the
buttons—by changing the text size, for
example—modifying the component
will cause all the buttons in the app to
change at once.

When the developer is working with a

canvas app, the tree view page has two
tabs: Screens and Components. On
the Components tab, shown in Figure
4-8, developers can create new
components, such as the button
shown, which will then be accessible
to any screen in the app. To insert a
component into an app screen, open
the Insert page and expand the
Custom header to see a list of the
components created in the app.
 ​

FIGURE 4-8 The Components tab in

a canvas app

Component Libraries

Components by themselves simplify

the process of unifying elements
throughout the various screens in an
app, but there are situations in which
developers might want to unify
elements across apps. For example, an
organization might want to create
multiple apps and have them all
utilize the same buttons and other
components. Component libraries are
one way to do this. A component
library is a repository for components
that exists independently from the
apps in which the components will be
used.

In the Power Apps portal, component

libraries are listed on the Apps page
under the Component libraries tab, as
shown in Figure 4-9. Developers can
create new component libraries here
and add components to them; the
process of creating components in a
library is virtually identical to creating
them in an app. After creating them,
developers can share component
libraries with other users.

FIGURE 4-9 The Component

libraries tab on the Apps page in the
Power Apps portal

To access a component library when

creating an app, a developer opens the
Insert page and clicks the Get more
components button at the bottom of
the screen. This generates a list of the
available component libraries, as
shown in Figure 4-10, from which the
developer can import individual
components or the entire library.

FIGURE 4-10 The Import

components pop-up on the Insert
page of a canvas app

After they are imported, the selected

components appear under a Library
components header in the Insert
pane, as shown in Figure 4-11. As with
components created within an app,
modifying a component in a library
can cause it to change in all the apps
where developers have used it. To do
this, however, the developer must
publish the component library after
making the changes and then update
the apps in which the library
components appear by clicking Check
for updates on the Insert page.

FIGURE 4-11 The Library

components header on the Insert page
of a canvas app

Power Apps Component Framework

The Power Apps Component

Framework (PCF) is another means of
creating and publishing components
that developers can import and use in
their apps. This type of code-based
component can transform displays
like the one shown in Figure 4-12 into
various types of graphics and charts,
as shown in Figure 4-13, and add
controls such as sliders and dials to
provide users with control over
numeric values. Code components can
also display information retrieved
from services outside the app.

FIGURE 4-12 Display without Power

Apps Component Framework

FIGURE 4-13 Display with Power

Apps Component Framework

Need More Review? PCF Coding

Unlike most of the Power

Platform tools and
technologies, PCF does require
the use of code, and Microsoft
has released a Power Apps CLI
(command-line interface) tool
that allows developers to
create and work on PCF code
components
https://aka.ms/PowerAppsCLI
.

As with component libraries, PCF

provides resources for developers that
can create a unified appearance and
experience across all of an
organization’s apps. There is also a
growing community of component
developers that make their work
available online on an open source
basis.

To deploy PCF code components,

developers package them into a
solution file and import the file into
the Common Data Service. From
there, individual app developers can
add them to canvas or model-driven
apps.

PCF code components must include

the following three elements:

■ Manifest—A metadata file in XML format that specifies the name of

the component, how it can be used, what properties can be configured,
and what resource files it needs

■ Component implementation—TypeScript or JavaScript code that

defines the functionality of the component and its user interface

■ Resources—A file containing the code needed to implement the

component’s visualization, which can include JavaScript libraries,
Cascading Style Sheets (CSS) code, images, and HTML

After the coding is completed, the

developer must package the code
components into a solution file using
the CLI pac command, generate a zip
file of the solution using the msbuild
command, and then manually import
the zip file into the Common Data
Service.

To use PCF code components in apps,

an administrator must first allow the
feature for the environment in which
the components are needed, using the
Power Platform admin center, as
shown in Figure 4-14.

FIGURE 4-14 The Environments

page in the Power Platform admin
center

Describe use cases for formulas

Formulas in Power Apps function in

much the same way as formulas in
Microsoft Excel. Developers can use
formulas to perform operations on
cell contents and to modify the
functionality of controls, such as
buttons, drop-down lists, and combo
boxes.

Performing operations with formulas

For example, just as people can use

the sum function in Excel to total a
column of cells, a developer can use
the sum function in a Power App to
add the numerical values in multiple
text boxes together. In Figure 4-15,
the sample app shown has three text
input controls called TextInput1,
TextInput2, and TextInput3 with
numerical text in them. The fourth
element is a label control with the
following multifunction formula in it:

FIGURE 4-15 The Power Apps

workspace containing a sample
canvas app with a Sum formula

Click here to view code image

Sum(Value(TextInput1.Text),Value(TextInput2.Text),Value(TextInput
3.Text))

In this formula, the Value function

converts the text in each of the first
three controls into a value that can be
manipulated. The Sum function then
adds the three values together into a
total that appears in the Label1
control. The developer can also
elaborate on the formula by adding
other functions, such as the If
function in the following example:

Click here to view code image

If(Sum(Value(TextInput1.Text),Value(TextInput2.Text),Value(TextIn
put3.Text)) >=65,​
"Pass","Fail")

This formula uses the If function to

evaluate the sum, as in the case of a
teacher calculating a quiz grade. If the
value arrived at by the Sum function is
greater than or equal to 65, then the
Label1 control displays Pass, as shown
in Figure 4-16; if the sum is less than
65, Fail appears.

FIGURE 4-16 The Power Apps

workspace containing a sample
canvas app with a formula using the If
function to evaluate a sum

Configuring controls with formulas

Power Apps can also use formulas to

configure controls. The Insert menu
in the Power Apps workspace
provides developers with a large
collection of controls that they can
add to canvas apps. After they are
added, controls have properties that
developers can configure using
formulas. All controls have properties
that define their appearance, such as
their size, color, and location on the
app screen. There are also properties
specific to the function of the control.

For example, when a developer inserts

the Date picker control into an app
screen, as shown in Figure 4-17, the
DefaultDate property shown in the
drop-down list in the top-left
quadrant of the app workspace has a
default formula value of Today(),
which appears on the app screen as
today’s date. The developer can
change that default formula value to
display any other date instead.

FIGURE 4-17 Configuring properties

in the Date picker control

Selecting the Format property in the

drop-down list displays a default
formula value of
DateTimeFormat.ShortDate, which
causes the date to appear in the
control using the format
mm/dd/yyyy. As shown in Figure 4-
18, developers can select that formula
to display alternative values, such as
ShortDateTime, which adds the time
to the date, and ShortDateTime24,
which adds the time using the 24-
hour clock.

Scrolling through the list of other

possible formula values, developers
can also select LongDate, which
displays the date in the control as
Friday, July 3, 2020.

FIGURE 4-18 Configuring the

Format property in the Date picker
control

SKILL 4.2: BUILD A BASIC

CANVAS APP

Canvas apps provide the developer

with complete control over the
formatting and appearance of the app.
The process of building a canvas app
involves connecting to a data source,
placing controls on the app screens,
and finally publishing and sharing the
app to make it accessible to
consumers.

This skill covers how to:

■ Describe types of data sources

■ Connect to data by using connectors

■ Combine multiple data sources

■ Use controls to design the user experience

■ Describe the customer journey

■ Publish and share an app

Describe types of data sources

Connecting to a data source is usually

the first step in creating an app in
Power Apps. This is true whether the
app is built on the source data or the
object of the app is to collect
information from the consumers and
save it.

An app can be based on data from any

one of hundreds of data sources,
accessed through the connectors
supplied with Power Platform, a few
of which are shown in Figure 4-19.

FIGURE 4-19 A sampling of

connectors supplied with Power
Platform

Organizations that subscribe to

Microsoft 365 have access to cloud-
based storage services that they can
use as data sources, including
OneDrive for Business and
SharePoint. Both of these services can
store files that contain the data on
which an app is based. Dynamics 365
and Power Apps Pro subscribers have
access to Common Data Services,
which is a database that apps can use
to store the data they gather from
users.

The many other connectors supplied

with the Power Platform tools provide
access to applications and services
running on local servers and in the
cloud. Power Platform has two classes
of connectors, standard and premium,
which are dependent on the Power
Apps/Power Automate license used by
the developers. The standard
connectors provide access to most of
the Microsoft cloud services, as well as
to basic internet services and social
media. The premium connectors allow
apps to connect to higher-end
commercial applications and services,
including SQL Server, Dynamics 365,
and various Azure services.

In some cases, a data source might

just be a place to store data generated
by the app, such as SharePoint or the
Common Data Service. In other cases,
the connection might be the source for
the data that is presented in the app,
as in the Flooring Estimates sample
app shown in Figure 4-20, which was
generated from an Excel spreadsheet
accessed from a OneDrive for
Business connection.

FIGURE 4-20 Sample app using

data from a spreadsheet stored on
OneDrive for Business

A spreadsheet is a type of table; this is

the most common form of data used
by apps in Power Apps. An app can
read data from a table, modify the
existing table data, and add new
entries to a table. Other types of
connections also can provide access to
tabular data, such as SharePoint lists
and SQL tables. Connectors can also
provide access to other types of data
that are not tabular, such as calendars
and email messages.

Connect to data by using connectors

Connecting to a data source is usually

the first requirement in building a
canvas app in Power Apps. How this
happens depends on how the
developer chooses to begin the build
process. As noted elsewhere in this
chapter, the Create page in the Power
Apps portal provides three ways to
create a canvas app:

■ Start with a blank app

■ Start with a data source

■ Start from a template

Starting with a blank app

If a developer chooses to begin from

scratch by selecting the Canvas app
from blank tile on the Create page, the
recommended first step is to navigate
to the Data sources pane. This pane
lists any current connections that are
open, the Common Data Service
entities that are available, if any, and
lists all the available connectors, as
shown in Figure 4-21.
 ​

FIGURE 4-21 Connectors available

in the Data sources pane

Depending on the nature of the

connector, the developer selecting it
will be presented with an interface
providing access to the application or
service. For example, if the developer
selects the Import from Excel
connector, a standard combo box
appears, enabling the selection of an
Excel file from a local or network
drive. If the developer selects the
connector for a subscription-based
online service, a window appears,
prompting for user account
credentials, as shown in Figure 4-22.

FIGURE 4-22 Sign-in pop-up

window for a connector
authentication

After the connection with the data

source is established, the developer
can begin building the app by adding
controls to the app screens. There is
nothing to prevent the developer from
designing the app screens and adding
controls before the data source
connection is in place, but only the
cosmetic aspects of the controls will
function.

Starting with a data source

The second method for creating a

canvas app is to start with a data
source and work from there. The Start
from data section on the Create page
contains icons for four of the most
commonly used data sources:
SharePoint, Excel Online, SQL Server,
and Common Data Service, as well as
an Other data sources link, which
opens the Create an app page shown
in Figure 4-23.

FIGURE 4-23 The Create an app

page in the Power Apps portal

Selecting one of the tiles in the Start

with your data section, such as the
OneDrive for Business tile, opens a
Connections page, as shown in Figure
4-24. In this example, the
Connections page indicates that there
is already an open connection to the
developer’s OneDrive for Business
account. If there was no existing
connection, the developer would have
to click the +New connection button,
select the OneDrive for Business
connector, and type the necessary
credentials to gain access to the data
source.

​
FIGURE 4-24 The Connections page
for a new app in the Power Apps
portal

With the connection established, the

developer can browse OneDrive for
Business and select a data file
containing tabular information that
Power Apps can use. In this example,
the chosen file is an Excel workbook
containing the spreadsheet partially
shown in Figure 4-25. Because an
Excel workbook can contain multiple
spreadsheets, a Choose a table pane
appears, listing all the spreadsheets in
the file for the developer’s selection.

FIGURE 4-25 Sample spreadsheet

used to create app

After the developer selects a data file,

Power Apps analyzes its contents and
creates a working app that utilizes the
data in an appropriate manner. In this
example, Power Apps uses the
spreadsheet information about types
of flooring to create a catalog app that
consists of the following three screens,
as shown in Figure 4-26:

FIGURE 4-26 Three screens from

the FlooringEstimates sample app

■ A Browse screen listing all the flooring products

■ A Detail screen for each product

 ■ An Edit screen in which users can modify the information for a
particular product

The design of this working app is

based on the data supplied in the file
and is basically Power Apps’ guess of
the developer’s intentions. The
developer can still modify the app in
any way. In fact, if the supplied design
is completely inadequate for the
developer’s needs, it might be easier
to start over from scratch with a blank
app and then connect to the data
source.

Starting with a template

As noted earlier, Power Apps includes

a collection of templates that consist
of app screen designs and data source
connections intended to perform a
specific task or solve a specific
problem. This is a different approach
to creating apps in that developers can
attempt to locate a template that
accommodates their needs as nearly
as possible.

Templates perform two basic

functions: they can serve as a
blueprint for an app the developer
actually needs, and they can be
training aids, demonstrating how
apps perform certain tasks. In many
cases, the templates included with
Power Apps include sample data and
prompt the developer to supply a data
storage connection such as OneDrive,
as shown in Figure 4-27. The
developer can then modify the app to
use different text, source data, and
images, as well as modify the controls
and add or remove screens.

​
FIGURE 4-27 App created from a
template prompting for a data storage
connection

Combine multiple data sources

Power Apps supports the use of

multiple data sources in a single app,
which developers can use in various
ways. When a developer uses a
connector to access a resource, it is
possible to access multiple tables or
other elements. For example, in the
sample app generated from an Excel
spreadsheet shown earlier, it would be
possible for the developer to connect
to more than one table in the same
Excel file. The initially generated app
is created from a single table, but the
developer can always add other tables
later. In that case, each table would be
considered a separate data source,
even though they both use the same
connection.

When apps are connected to multiple

data sources, using one connection or
more than one, the app can use them
for incoming or outgoing data. An app
can combine existing tables from
multiple data sources, such as the
product inventories from several
branch stores, and combine them into
a catalog app that provides a picture
of the available inventory for the
entire chain.

It is also possible to use multiple data

source connections for different
purposes. For example, an app can
conceivably use one connection to
retrieve data from a branch office in
an Excel file, allow users to modify the
data table in the app, and then use
another connection to save the revised
data to the environment’s Common
Data Service in the cloud.

Use controls to design the user experience

With connections in place, the actual

process of designing an app in Power
Apps involves placing controls and
other elements on the app screens to
create a usable interface for the
consumers who will be running it. The
term control refers here to any of the
display elements found on an app
screen. The title box at the top of the
screen, the buttons that trigger
functions, and the panels containing
data from your source are all
examples of controls.

One of the best ways to learn about

controls is to explore the ones created
automatically when you generate an
app from a data source or a template.
The three screens shown earlier from
the sample FlooringEstimates app are
typical of an app generated from a
tabular data source. These screens are
as follows:

■ Gallery—The gallery screen, shown in Figure 4-28 and called

BrowseScreen1 in the sample app, displays the table data from the
connected source as a scrolling list, with each product box containing the
data from one row in the table. The gallery control (called
BrowseGallery1) is the primary control for the screen, occupying most of
its real estate. The other controls listed in the Tree View pane implement
the other elements on the screen, including the title bar (called a label
control), the buttons on the title bar (called icon controls), and the search
box (called a text input control). The BrowseGallery1 control in the Tree
View pane is expandable because it contains other controls that create the
contents of each box in the gallery.

FIGURE 4-28 The BrowseScreen1 screen in a Power Apps sample app

■ Detail—The detail screen, shown in Figure 4-29 and called

DetailScreen1 in the sample app, displays all the information for one
product selected from the gallery. Apart from the label and icon controls
in the title bar, the screen consists mostly of card controls, which contain
the individual data elements corresponding to the cells in the source
spreadsheet.

​
 FIGURE 4-29 The DetailScreen1 screen in a Power Apps sample app

■ Edit—The edit screen, shown in Figure 4-30 and called EditScreen1 in

the sample app, displays the same information as the detail screen, but in
editable controls so that the user can modify the information. Instead of
simple card controls, which only display the data, this screen uses text
input controls to contain the individual data points so that the user can
modify them. All of these editable controls are part of an edit form
control.

FIGURE 4-30 The Edit screen in a Power Apps sample app

When working in the Power Apps

Studio portal, clicking any element in
a screen highlights the corresponding
control in the Tree View pane and
displays the properties of the control
in the right pane. All controls have
properties that specify how they look
and what they do. The right pane in
the Studio interface contains some of
the properties for the selected control,
using text boxes, buttons, and drop-
down lists to allow the developer to
modify the property values.

An equation bar near the top of the

interface contains a drop-down list for
selecting a property and an interactive
function box, as shown in Figure 4-31,
in which the developer can work with
the individual property values. In the
sample, the Data Source property of
the EditForm1 control on the edit
screen indicates that the data comes
from the spreadsheet, identified as
@FlooringEstimates.

FIGURE 4-31 The equation bar from

the Power Apps Studio interface

This FlooringEstimates app contains

only a small sampling of the controls
available to developers in Power Apps
and how they can make use of them.
The insert bar, above the equation bar
in the figure, contains buttons and
drop-down menus that allow the
developer to insert controls anywhere
on an app screen. The buttons and
menus include the following:

■ New screen—Adds screens of various types to the bottom of the Tree

View from a gallery of thumbnails, including list, form, email, and
calendar formats

■ Label—Adds a text box intended for display text

■ Button—Adds a rectangular blue button that developers can resize and

recolor as needed

■ Text—Adds a box for the display and/or insertion of text in various

formats, including plain text, HTML, rich text, and pen input

■ Input—Adds controls that allow users to supply data, including text

boxes, drop-down lists, combo boxes, date pickers, check boxes, radio
buttons, and toggles

■ Media—Adds controls that allow apps to display images, audio, and

video, as well as accept user input from cameras and barcode scanners

■ Charts—Adds controls that can display the source data as column,

line, or pie charts, as well as insert Power BI tile

■ Icons—Adds controls that display small icons, such as plus signs,

pencils, and check marks, which can function as buttons

■ Custom—Allows developers to create, import, and export components

■ AI Builder—Allows the insertion of standard AI Builder functions,

such as the business card reader, the form processor, and the object
detector

Describe the customer journey

The customer journey is the complete

experience that a consumer undergoes
while working with a company or
organization. The customer’s
experience can include interactions
with salespeople, customer service
representatives, technical support
personnel, and others. Power Apps
can enhance the customer’s journey
by providing these company
representatives with all the
information they need to satisfy the
needs of the customer.

Custom apps running on smartphones

or other mobile devices can ensure
that company reps have up-to-date
information about the products they
sell and service. For example, using
Power Apps with AI Builder,
developers can create applications
that supply sales and servicepeople
with current inventory information,
ensuring that the promises they make
to customers can be fulfilled, that the
products they need are available, or
that the parts required to effect a
repair are in stock.

Publish and share an app

After developers finish building their

apps, they have to save them and
share them with the users who will
access them. When a developer later
makes changes to an existing shared
app, the developer must publish the
app so that the latest version is
supplied to the users.

When a developer saves a canvas app

for the first time, Power Apps opens a
page that provides the option to save
it to the cloud or to the local
computer, as shown in Figure 4-32.
After this first save, Power Apps
automatically saves any changes made
to the app every two minutes.

FIGURE 4-32 The Save as page in

the Power Apps portal

After the app is successfully saved, the

success screen includes a Share
button. Clicking this opens the Share
page, on which the developer can
specify a user or group with which the
app will be shared, as shown in Figure
4-33. By default, the accounts added
on the Share page become users, who
are permitted to run the app.
Selecting the Co-owner check box
grants the user the permissions
needed to edit the app and share it
with others.
 ​

FIGURE 4-33 The Share page in the

Power Apps portal

After the app is saved, it is still

possible for the developer or the co-
owners to modify it, and Power Apps
saves the changes every two minutes.
However, it is necessary to publish the
app to supply the sharing users with
the latest version. Selecting Save from
the File menu after making changes to
an app produces a page with a Save
button, and then another page with a
Publish button. Clicking Publish
causes the Publish pop-up shown in
Figure 4-34 to appear.

FIGURE 4-34 The Publish pop-up in

the Power Apps portal

SKILL 4.3: DESCRIBE POWER

APPS PORTALS

As mentioned earlier in this chapter, a

Power Apps portal app is a means of
creating a website that allows internet
and intranet users to access data
stored in a Common Data Services
database. To run a canvas or model-
driven app requires a Portal Apps
license, so these types of apps are
intended for an organization’s
internal use. However, portal apps
make it possible for unlicensed users
to access data that developers have
previously stored in Common Data
Services.

This skill covers how to:

■ Create a portal by using a template

■ Describe common portal customizations

■ Identify differences in portal behavior based on whether a user is

authenticated

■ Apply a theme to a portal

Create a portal by using a template

In its default configuration, a

developer with a Power Apps license
can create a blank portal, but no
portal templates are listed on the
Create page. Creating a blank portal
uses the Common Data Services
database installed in the selected
environment as its data source,
eliminating the need to establish
outside connections.

If the currently selected environment

does not have the required entities
and other components installed,
creating a portal using the Portal from
blank pop-up window, as shown in
Figure 4-35, installs the necessary
prerequisites—including a starter
template—along with the portal app
itself.

FIGURE 4-35 The Portal from blank

pop-up window

The starter portal includes three

sample webpages that developers can
use as the basis for their own page
designs, as follows:

■ Default Studio template

■ Page with title

■ Page with child links

When a developer who is a Dynamics
365 subscriber has model-driven
Dynamics 365 apps installed in the
currently selected environment, then
the Create page includes portal
templates associated with the
Dynamics 365 apps, as shown in
Figure 4-36.

FIGURE 4-36 Dynamics 365 portal

templates

Installing a portal app from a

template first calls for the developer
to supply a name for the app and the
address with which users will access it
in the powerappsportals.com
(http://powerappsportals.com) domain, as

shown in Figure 4-37. The form

checks the address supplied by the
developer to ensure that it is not
already in use. After the developer
clicks Create, the window closes and
the portal provisioning process
proceeds in the background, often for
several minutes.

FIGURE 4-37 The Customer self-

service pop-up generated by a portal
app template

While the provisioning occurs, the

new portal app is listed on the Apps
page, as shown in Figure 4-38, but it
is grayed out and the icon has a
progress symbol, indicating that it is
not yet accessible.

FIGURE 4-38 A provisioning portal

app, listed on the Apps page

After the provisioning is complete, the

portal app is ready for editing and/or
browsing. The template provides
sample data that populates the app
with fully functional features
appropriate to the application. In the
case of the Customer Self-service
portal, shown in Figure 4-39, there is
a knowledge base, discussion forums,
a support page, and a search engine.

FIGURE 4-39 The home page of a

Customer Self-service portal app

Describe common portal customizations

The starter page generated by a portal

app created from a blank has a
rudimentary design that is only
intended to provide the developer
with a basic structure on which to
build. A substantial web development
effort is necessary to make the website
functional enough for clients to use.

By contrast, a portal app created from

a template supplied by Dynamics 365
uses a far more attractive and
comprehensive design that includes
web applications, such as a search
engine, a knowledge base, and
threaded discussion forums.

The portal app templates include

sample data for the websites they
create that conform to a sample
business application that is
appropriate for the type of portal. For
example, the Customer Self-service
portal app creates a sample website
for a company called Contoso, Ltd.
that contains material on supporting
3D printers and audio equipment.
Obviously, the app developer will have
to modify the site design to change the
company name and populate the site
with customer service articles and
other material appropriate to the
developer’s business.

Portal Apps provides a WYSIWYG

(what you see is what you get)
workspace that allows developers to
edit the website pages in place. The
toolbar in the left pane provides the
following editing tools:

■ Pages—Provides access to each of the pages on the portal website and

the ability to create new pages, as shown in Figure 4-40

FIGURE 4-40 The Pages menu in

Portal Apps Studio

■ Components—Allows developers to add elements to webpages,

including text, images, frames, forms, and lists, as shown in Figure 4-41
 ​

FIGURE 4-41 Sampling of the

Components menu in Portal Apps
Studio

■ Themes—Provides access to prebuilt CSS themes that modify the color

and other cosmetic attributes of the portal website, as shown in Figure 4-
42

FIGURE 4-42 The Themes menu in Portal Apps Studio

■ Templates—Provides access to editable blocks of code that define the

layout of a webpage, as shown in Figure 4-43, enabling developers to
reuse page designs across multiple websites. The Template drop-down
list in each page’s properties pane specifies the page template it is using.

FIGURE 4-43 The Templates menu in Portal Apps Studio

Exam Tip

Candidates for the PL-900 exam

 should be careful not to confuse
the page templates that define the
layout of portal webpages with the
app templates on the Create page
that are used to create sample
apps.

A developer might choose to

customize the existing website
generated by the app template by
completely redesigning the website,
by creating new pages, by applying
themes and/or templates, and by
adding components to them. In other
cases, developers might prefer to use
the site produced by the template,
changing only what is necessary to
accommodate the organization’s name
and content.

Identify differences in portal behavior

based on whether a user is authenticated

In some cases, the portal apps

generated from templates provide
users with access to sensitive
information, and they therefore
require the user to authenticate before
full access to the website is granted. It
is possible to create a portal in which
users can access some or even all of
the content anonymously, such as a
technical support portal that provides
general information for all users of a
product, but for customer service,
employee, or partner portals and the
like, authentication will be necessary
to provide access to user-specific
information.

Portal apps, by default, use local

authentication based on accounts
realized in the Contact entity of the
Common Data Services database.
Developers can register users by
having them fill out a form, as shown
in Figure 4-44, which provides the
information that goes into a contact
record. For greater control over the
registration process, developers can
require users to validate their email
addresses or supply an invitation
code. Portal apps also support
external authentication methods,
using Azure AD accounts or social
media providers, such as Google.

FIGURE 4-44 The Register for a

new local account page from a portal
app

Apply a theme to a portal

Themes are Cascading Style Sheets

(CSS) definitions that specify the
attributes to be applied to the
webpages generated by a portal app.
CSS is a standard web design tool
used by many internet websites. The
themes in the Portal Apps Studio
interface are simply sequences of CSS
code that developers can apply to
portal pages, or even to multiple
portal websites, to create a uniform
appearance.

The Themes menu in the Portal Apps

Studio interface contains a selection
of themes, which developers can apply
as is or modify as needed. Opening a
theme displays it in a Code Editor
window, as shown in Figure 4-45.

FIGURE 4-45 CSS code for a theme

in a portal app
CSS code contains attributes and
values that web browsers use to
configure text, colors, and other
elements of webpages as they render
them. For example, the text-align
attribute in CSS code specifies
whether a given block of text should
be left-justified, right-justified, or
centered. The font-size attribute
specifies the text size. Therefore, the
following syntax causes the selected
text to be 36 pixels and centered,
typical for a section heading on a
webpage:

Click here to view code image

{​
font-size: 36px;​
text-align: center;​
}

When a developer modifies the CSS

code for a particular theme, selecting
Upload custom CSS from the Themes
menu makes it possible to add the
revised code as a new theme that will
be accessible on other webpages.

SKILL 4.4: BUILD A BASIC

MODEL-DRIVEN APP

Rather than concentrating on

interface design, as some developers
tend to do when building canvas apps,
model-driven apps are centered
around the data they gather and
present and the business processes
they realize for users. Developers
concentrate on what they want the
app to do, rather than how it will look
or function. Power Apps is responsible
for the interface design.

This skill covers how to:

■ Add entities to app navigation

■ Modify forms and views

■ Publish and share an app

Add entities to app navigation

Model-driven apps have the same

creation options as canvas apps. The
Create page in the Power Apps portal
contains a Model-driven app from
blank tile as well as several model-
driven templates.

Using the templates requires a

Common Data Services database and
the sample apps included with Power
Apps. If the database and the samples
do not exist in the current
environment, Power Apps offers to
create a new environment that
includes both, as shown in Figure 4-
46.

FIGURE 4-46 Power Apps model-

driven app template message box

Exam Tip

Candidates for the PL-900 exam

can install a trial version of Power
Apps, as well as a trial version of
Dynamics 365, to sample the full
Power Apps experience. The trial
versions are time-limited, and
there is also a limit of one trial
environment.

The real difference between building

model-driven apps and canvas apps
comes after the app is installed.
Instead of the canvas app workspace
showing a facsimile of the app screens
that the developer can populate by
dragging and dropping WYSIWYG
components, model-driven apps have
an App Designer workspace, like the
one shown in Figure 4-47.
 ​

FIGURE 4-47 The App Designer

interface for a model-driven app

As with canvas apps, model-driven

app designs are based on components,
but in the App Designer interface, the
components do not resemble the
elements as they will appear on the
final app screens. Model-driven app
screens are based on tiles, and
developers use the App Designer to
specify what tiles should appear, what
data they contain, and how that data
should be presented.

Model-driven apps also differ from

canvas apps in that they are always
based on data accessed from the
Common Data Services database.
Developers design the app by adding
entities from the database.

For example, in the Innovation

Challenge app shown in the previous
figure, the App Designer has nine
rows in the Entity View section, the
first four of which are visible in the
figure: Challenge, Document
Location, Feedback, and Idea. The
entities appear as buttons on the left
side of the screen, and each entity has
a row of four icon boxes representing
the entity assets: Forms, Views,
Charts, and Dashboards. These are
the elements that determine what
data will appear in the final app and
how it will be presented.

Developers can add entities to the app

by clicking the Entities artifact on the
Components tab and selecting from
the list shown in Figure 4-48.
Selecting a check box adds the entity
to the Entity View area, creating a new
row of assets for the developer to use.

FIGURE 4-48 Entity selection check

boxes

The entities available to the app are

those found in the Common Data
Services database for the selected
environment. Developers can add to
the capabilities of model-driven apps
by adding entities to the database and
populating them with attributes and
records. Model-driven apps can also
run users through business processes
that create new records in specific
entities and add data to them.

When a user runs the Innovation

Challenge sample app, it appears as
the dashboard shown in Figure 4-49.
The entity assets appear as tiles,
which the app can shift around
depending on the size of the screen
displaying it. Developers do not
choose a tablet or phone format in a
model-driven app, as they do in a
canvas app; the app itself controls the
display.
 ​

FIGURE 4-49 The Innovation

Challenge sample model-driven app

Modify forms and views

In the Innovation Challenge sample

app, the first row of tiles in the
dashboard, as shown in the previous
figure, contains two charts called
Active Challenges and a list called
Active Ideas. The configuration of the
entity assets for Challenge and Idea
rows in the App Designer are what
make the data from those entities
appear as they do.

For example, in the App Designer

interface for this app, the Challenge
entity has a number 2 in its Charts
asset box. Selecting that box displays
the Select Charts interface in the
Components pane, as shown in Figure
4-50. The two check boxes selected
are Active Challenges by Domain and
Most popular Challenges, which, not
coincidentally, are the two charts that
appear in the Innovation Challenge
dashboard.

FIGURE 4-50 The Select Charts

interface in the Components pane of a
model-driven app

Clicking the down arrow in the Charts

asset box opens a drop-down list with
the names of the two charts, each with
an edit icon that opens the Chart
Designer window, as shown in Figure
4-51. In this window, the developer
can change the appearance of the
chart by selecting a chart type and
configuring its properties.

FIGURE 4-51 The Power Apps Chart

Designer interface

Forms appear in model-driven apps

when users view entity data in a table
format and click the New button to
create a new record in the entity. For
example, selecting the Challenges
screen in the Innovation Challenge
app and creating a new record
displays the form shown in Figure 4-
52, which is similar in appearance to a
business process flow in Power
Automate, taking the user through
multiple stages, beginning with Setup,
with several steps to complete in each
stage.

FIGURE 4-52 The New Challenge

form in a model-driven app

As with the Charts asset box, the

Forms asset box provides an edit
button for each of the forms
appearing in the drop-down list. The
edit button opens the Form Editor
interface, as shown in Figure 4-53.
The Form Editor has a WYSIWYG
display of the form in the center pane.
In the left pane, the developer selects
the fields that will appear in the form,
and the right pane contains the
configurable properties for the
selected field. After modifying the
form, the developer must save the
changes and publish the form so that
it can appear in the live app.

FIGURE 4-53 The Power Apps Form

Editor interface

A view in a model-driven app is a

display of information from the
Common Data Services database in
tabular form, as shown in Figure 4-54.
Views can also appear on dashboards
as scrollable lists, as shown earlier.

FIGURE 4-54 A view page in a

model-driven app

Developers can modify views from the

entity asset boxes just as they can
charts and forms. The View Editor
interface, shown in Figure 4-55, is
similar to the Form Editor, with
selectable fields listed in the left pane,
editable properties in the right pane,
and a real-time display of the view in
the center pane, to which the
developer can add and remove
columns.

FIGURE 4-55 The View Editor

interface in a model-driven app

Exam Tip

Candidates for the PL-900 exam

should be aware that all the
designer interfaces for the entity
assets have been updated recently,
and the new versions—called the
new experience—are now the
defaults. However, many of the
documents and resources online
are still based on the previous
interfaces. All of the designers also
have a Switch to classic button
that allows developers to use the
previous interface.

Publish and share an app

After working with a model-driven

app, the developer must save the
changes using the Save button in the
top-right corner of the App Designer
interface. Saving the changes activates
the Validate and Publish buttons.
Validating the app checks the
components for asset dependencies
and any other issues that could affect
their performance and displays error,
warning, or information messages like
those shown in Figure 4-56.

​
FIGURE 4-56 Error and warning
messages detected by the app
validation process

After addressing any problems with

the app, the developer must click the
Publish button. Doing so activates the
Play button in the App Designer and
also makes the updated version of the
app available to Power Apps users.

For users to run model-driven apps,

the developer must share the app with
the individual users or a group to
which the users belong. Security for
model-driven apps is role based.
Power Apps has predefined roles that
might be appropriate for some apps,
or the developer can create custom
roles that contain the permissions
needed to run an app.

To share an app in Power Apps, the

developer selects the app and clicks
the Share button to open the Share
pop-up for that app. Selecting the app
allows the developer to select the
predefined standard roles to assign to
users. Then, the developer supplies a
user or group name in the People text
box, chooses the correct user, and
selects the role to assign to the user,
as shown in Figure 4-57. If the
predefined security roles are not
appropriate for the app, the developer
can click Manage security roles and
create a new custom app.

FIGURE 4-57 The Share pop-up

interface for a specific model-driven
app

CHAPTER SUMMARY
■ Power Apps is designed for citizen developers with little or no coding
experience.

■ Developers create canvas apps by dragging and dropping elements

onto screens in Power Apps Studio; model-driven apps do not provide the
same interface configuration capability.

■ A portal app is a means of providing users—both internal and external

—with access to data stored in the Common Data Service using a website.

■ The process of building a canvas app involves connecting to a data

source, placing controls on the app screens, and finally publishing and
sharing the app to make it accessible to consumers.

■ The actual process of designing a canvas app involves placing controls

on the app screens to create a usable interface for the consumers who will
be running it.

■ After developers finish building their apps, they have to save them and
share them with the users who will access them.

■ Creating a blank portal uses the Common Data Services database

installed in the selected environment as its data source.

■ The starter page generated by a portal app created from a blank has a
rudimentary design that is only intended to provide the developer with a
basic structure on which to build.

■ Portal apps, by default, use local authentication based on accounts

realized in the Contact entity of the Common Data Services database.

■ Themes are Cascading Style Sheets (CSS) definitions that specify the
attributes to be applied to the webpages generated by a portal app.

■ Model-driven apps are centered around the data they gather and
present and the business processes they realize for users.

■ Model-driven app designs are based on components, but in the App

Designer interface, the components do not resemble the elements as they
will appear on the final app screens.

■ Forms appear in model-driven apps when users view entity data in a

table format and click the New button to create a new record in the entity.

THOUGHT EXPERIMENT

In this thought experiment,

demonstrate your skills and
knowledge of the topics covered in
this chapter. You can find answers to
this thought experiment in the next
section.

Ralph is experimenting with Power

Apps, the license for which he
obtained with his Dynamics 365
subscription. He is trying to develop a
canvas app that will allow his
company’s salespeople to enter order
information on their smartphones.
The orders are to be saved to an order
entry database on the company’s SQL
Server. Ralph has created a suitable
interface for the app, with fields in
which the salespeople can specify the
customers and the products they want
to order. The app seems to be working
properly during Ralph’s in-house
testing, but when he attempts a trial
deployment to a small group of
salespeople in the field, the order
information is not being written to the
SQL database. Which of the following
could be the problem?

1. a. The salespeople are using a Power Apps version that does not
support connections to a SQL Server.

2. b. The salespeople do not have adequate permissions to write to the

SQL database.

3. c. The SQL server is not accessible from a mobile data network.

THOUGHT EXPERIMENT
ANSWERS

A, b, or c. Any of the three answers

could potentially be the cause of the
problem experienced by the
salespeople.

1. a. If the salespeople are not using a Power Apps license that supports
premium connectors (of which the SQL Server connector is one), they
will not be able to access the database. Ralph has obtained his Power
Apps license with his Dynamics 365 subscription, which includes
support for premium connectors.

2. b. The salespeople must log on to the SQL Server to access the

database, and if their accounts do not have the appropriate
permissions, as Ralph’s evidently does, they will not be able to save
their order entry information to the database.

3. c. If the SQL server is hosted by a physical computer in the

company’s data center, Ralph is presumably accessing it through the
company network. The salespeople in the field might not be able to
access the SQL server using their mobile data networks from outside
the company’s facility.
Chapter 5

Demonstrate the
capabilities of Power
Automate
As the name implies, Microsoft Power
Automate is a tool that allows
developers to automate commonly
performed, repetitive tasks. Many
applications have the ability to
automate their own tasks, but Power
Automate can automate sequences of
tasks that involve multiple
applications and services. For
example, it is possible to use Power
Automate to generate an email
notification each time a tweet is
posted that is addressed to a specific
hashtag. The sequences of tasks
Power Automate creates are called
flows. In fact, the Power Automate
product was until recently known as
Microsoft Flow.

Skills covered in this chapter:

■ 5.1: Identify common Power Automate components

■ 5.2: Build a basic flow

SKILL 5.1: IDENTIFY COMMON

POWER AUTOMATE
COMPONENTS

This skill covers how to:

■ Identify flow types

■ Describe use cases for and available templates

■ Describe how Power Automate uses connectors

■ Describe loops and conditions including switch, do until, and apply

to each

■ Describe expressions

■ Describe approvals

Power Automate is a tool that does

not require any coding knowledge; it
uses a graphical interface in the Power
Automate portal to create sequences
of events called flows that are
themselves divided into elements
known as triggers and actions. A
trigger is an event that launches the
flow, and actions are the tasks that
the flow performs after it is launched.

Identify flow types

The Power Automate portal provides

developers with dozens of flow
templates, a few of which are shown
on the My flows screen at the bottom
of Figure 5-1. Flow templates are
essentially combinations of various
triggers and actions.

FIGURE 5-1 The My flows screen in

the Power Automate portal

However, it is also possible to create a

flow from scratch. When you click the
+New button on the My flows screen,
a drop-down list appears, as shown at
the top left of the figure, and you can
opt to create a flow from a template or
choose one of the following flow
types:

■ Automated (see Figure 5-2)—A flow that is triggered automatically

when a specific event occurs, such as the arrival of an email or the posting
of a file

FIGURE 5-2 The Build an automated flow page in the Power Automate
portal

■ Instant (see Figure 5-3)—A flow (also called a button flow) that is
triggered manually by a user clicking or tapping a button or other control

​
 FIGURE 5-3 The Build an instant flow page in the Power Automate
portal

■ Scheduled (see Figure 5-4)—A flow that is configured to launch at a

specific date and time or by a recurring schedule

FIGURE 5-4 The Build a scheduled flow page in the Power Automate
portal

■ UI flow (see Figure 5-5)—A flow that automates the playback of

recorded tasks in legacy applications requiring mouse clicks and/or
keyboard input

FIGURE 5-5 The Create a UI flow page in the Power Automate portal

■ Business process (see Figure 5-6)—A flow that leads users through the
individual stages and steps of a process needed to complete a task

FIGURE 5-6 The Build a business process flow page in the Power
Automate portal

Describe use cases for and available

templates

Power Platform has hundreds of

connectors that provide access to
Microsoft and third-party applications
and services, which Power Automate
developers can use in innumerable
combinations when creating flows.
The Power Automate tool can support
advanced development projects, but it
is actually designed for beginning
users that Microsoft often calls citizen
developers. To simplify the process of
getting started in creating Power
Automate flows, the tool also includes
dozens of templates, a small sampling
of which are shown in Figure 5-7.

FIGURE 5-7 The Templates screen

in the Power Automate portal

Templates are examples of flows

using various combinations of
connectors that are designed to
perform common business tasks
involving multiple applications and
services. Each template appears as a
tile, as shown in Figure 5-8, which
contains a summary of the tasks the
flow accomplishes, the template’s
author, how the flow is triggered, and
icons indicating the connectors the
flow will use.

FIGURE 5-8 The Notify me in

Outlook when a student completes a
quiz template tile in the Power
Automate portal

For example, users can easily

configure Microsoft Outlook to
generate a notification in Windows 10
whenever a new email arrives; doing
so does not require any special
programming or outside software.
However, if a teacher wants to receive
Outlook email notifications whenever
students submit quiz responses in
Microsoft Forms, this requires
communication between Forms and
Outlook that is not readily possible
within the applications themselves.

As shown in the previous figure,

Power Automate includes a template
for a flow that makes these
notifications possible. When a user
selects the template tile, a detail
screen appears that summarizes the
tasks performed by the flow and lists
the connectors it will use, as shown in
Figure 5-9.

FIGURE 5-9 Detail screen for the

Notify me in Outlook when a student
completes a quiz flow template in the
Power Automate portal

Note Connector Credentials

By default, most connectors

will use the credentials of the
currently logged-on user when
accessing outside applications
and services. If the given
credentials do not
authenticate properly, or if
there is a reason to use a
different account, the
developer can switch accounts
for a selected connector and
supply new credentials.

Clicking Continue on the detail screen

for the flow displays the workspace
canvas containing the individual
trigger and action elements of the
flow, as shown in Figure 5-10. On this
canvas, the developer provides the
details needed for the flow to
function. Controls are also available
that the developer can use to
customize the flow to perform
additional tasks.

FIGURE 5-10 The workspace canvas

for the Notify me in Outlook when a
student completes a quiz template

A generic template like this one

obviously cannot include all the
details necessary for the flow to run.
In this case, the developer must
supply information such as the name
of the form to monitor and the subject
line and message text to be used in the
notification emails.

Flows are not limited to one trigger

and one action, and there are
templates that perform multiple
actions when triggered. For example,
the template shown in Figure 5-11
expands on the previous one by not
only sending a notification email, but
also by storing the students’ quiz
responses in a SharePoint list.
 ​

FIGURE 5-11 Detail screen for the

Notify me and store the response
when a student completes a quiz
template in the Power Automate
portal

The workspace canvas for this

template, as shown in Figure 5-12,
approaches the tasks somewhat
differently than the previous one. This
template uses the Notifications
connector to send the email and adds
a SharePoint action that saves the
form response to a list selected by the
developer.

FIGURE 5-12 The workspace canvas

for the Notify me and store the
response when a student completes a
quiz template in the Power Automate
portal

All the templates provided in the

Power Automate portal can be used as
is or modified to suit the needs of the
developer. The bottom of the canvas
always includes an Add an action
button that opens the Choose an
action dialog box, as shown in Figure
5-13, which the developer can use to
add another task to the flow.

FIGURE 5-13 The Choose an action

dialog box from the workspace canvas
for the Notify me and store the
response when a student completes a
quiz template in the Power Automate
portal

The Templates screen in the Power

Automate portal allows users to
search for specific templates or
browse through the tiles representing
the hundreds of flow templates
included with the tool. A series of tabs
break the collection of templates
down into categories, including the
following:

■ All flows—Displays all the available flow templates

■ Featured—Displays a selection of the most popular flow templates

■ Shared with me—Displays flow templates that other users in the

organization have shared with you

■ Remote work—Displays a selection of flow templates appropriate for

users working from remote locations
 ■ Approval—Displays flow templates requesting or granting manager
approval for specified tasks

■ Button—Displays templates for instant flows that are triggered by a

manual button click or tap

■ Visio—Displays templates that allow developers to use Microsoft Visio

to design workflows

■ Data Collection—Displays flow templates that save, copy, or move

incoming data

■ Email—Displays flow templates that manage or generate email

messages

■ Events and calendar—Displays flow templates that create and manage

calendar events

■ Mobile—Displays templates for flows that are designed for use on

mobile clients

■ Notifications—Displays flow templates that generate notifications

■ Productivity—Displays flow templates that create and manage tasks in

productivity applications, such as SharePoint and Teams

■ Social media—Displays flow templates that perform tasks in social

media applications

■ Sync—Displays flow templates that copy, move, or synchronize files

between accounts, folders, or applications

Describe how Power Automate uses

connectors

The Power Platform tools use

connectors to access data sources in
various ways. Power Automate uses
connectors in flows for both triggers
and actions.

Need More Review? Connectors

For more information on

connectors and their use in the
Power Platform tools, see the
“Skill 2.2: Describe
Connectors” section in
Chapter 2, “Identify the core
components of Power
Platform.”

Connector types

Power Automate uses connectors to

establish two basic types of data
source connections:

■ Function-based—Refers to connections that use functions to perform

tasks on the source application or service. Triggers often use functions to
monitor activity at the source, allowing them to launch a flow when a
specific event occurs, such as the arrival of a file or email. Flows also use
functions for actions, allowing them to send an email, create a calendar
event, modify permissions, or generate a notification.

■ Tabular—Refers to connections that allow a flow to retrieve data from

the source application or service in a table format. Flows can use tabular
data as triggers, to provoke an action when the data is changed, for
example. However, flows more often use tabular data as part of an action,
to copy it to another location, for example. When Power Apps uses a
Power Automate flow as part of its functionality, it can conceivably use a
connector to create, modify, or remove data on the source.

Connection permissions
When Power Automate uses a
connector in a flow, it is nearly always
necessary for the connector to
authenticate to the outside application
or service before it can access the data
source. The connector must therefore
have the credentials necessary to
complete the authentication. When a
flow uses multiple connections to
different data sources, each connector
must supply credentials to perform its
own authentication.

When a developer creates a flow by

selecting a template tile, a detail
screen appears, the bottom half of
which lists all the connectors needed
for the flow, as shown in Figure 5-14,
as well as the account names that will
be used to establish the connections.
Many connectors, by default, use the
credentials of the currently logged-on
user to connect to the data source, but
this is not always appropriate or
possible. The developer might want to
use different accounts, or the user
might prudently have different
passwords for the various applications
and services.

FIGURE 5-14 A flow template detail

screen with five connections
In this particular template, the Office
365 Users and Office 365 Outlook
connectors are using the current
account, and the green check marks
indicate that the connectors will
authenticate successfully. The
remaining three connectors have blue
plus signs, indicating that they are not
prepared to authenticate, and that the
developer needs to specify the
accounts they will use to access the
data sources.

Until that is done, there is a grayed-

out Retry button at the bottom of the
screen; when all of the connectors are
ready to authenticate, it changes to a
blue Continue button, allowing the
developer to move on in the process of
creating the flow.

When the developer clicks one of the

blue plus signs or the Switch account
button on a connector that already
has an account listed, a Sign in to your
account screen appears, as shown in
Figure 5-15, in which the developer
can select a user account or specify a
new one. Depending on the connector
and the nature of its authentication,
the screen prompting for credentials
might be different in appearance.

​
FIGURE 5-15 The Sign in to your
account screen from the Power
Automate portal

When a developer creates a flow from

scratch or modifies an existing flow, it
is always possible to change the
credentials that a connector uses to
authenticate with a data source. On
the workspace canvas, every trigger
and action step has a menu button on
the right side. The menu includes a
My connections section, in which the
developer can choose an existing
account or click the +Add new
connection button, as shown in Figure
5-16.

FIGURE 5-16 Two steps in a flow on

the Power Automate workspace
canvas

One important consideration for

developers configuring connectors in
Power Automate flows is whether they
want the consumers of the flow to be
able to use the same authentication
credentials specified during its
creation. When developers create
automated flows, the credentials they
specify for the connectors are used
whenever the flow runs. Adding co-
owners to an automated flow allows
them to change the credentials as
needed.

When developers create instant flows

—flows that are manually triggered—
they can designate other users as co-
owners or run-only users. For run-
only users, the developer can specify
whether the consumers can use the
credentials already supplied during
the creation of the flow or must
supply credentials of their own for the
connectors. Consumers can then
configure the flow to access their own
accounts instead of the developer’s, as
in the case of a flow that must access
the consumer’s email.

Exam Tip

Candidates for the PL-900 exam

should be conscious of credential
security issues when designing
and building flows. There can be
situations when a developer’s use
of administrative credentials while
creating a flow can allow the flow’s
consumers to access sensitive
data.

Describe loops and conditions including

switch, do until, and apply to each

In its simplest form, a Power

Automate flow consists of a series of
steps performed in sequence, one
trigger, and at least one action. When
the last action is completed, the
processing of the flow ends. However,
it is possible to create more complex
flows that take nonlinear paths, such
as those that contain conditional
branching or processing loops.

Conditional flows

A flow can contain a condition, which

is an if/then statement that defines
two possible actions. For example, an
automated flow can contain a trigger
that causes it to run whenever a new
email arrives in a specific mailbox. A
Condition action can then check
whether the email message was sent
with high importance, as shown in
Figure 5-17. The Condition step then
branches into two possible actions:
the If yes action if the message was
sent with high importance and the If
no action if it was not. The If yes
action can cause a notification to be
sent to the user’s smartphone, and the
If no action does nothing.

FIGURE 5-17 A Condition branch in

an automated flow

To create a conditional branch, the

developer creates a new step and, in
the Choose an action dialog box, clicks
the Built-in tab and selects the
Condition action, as shown in Figure
5-18.

FIGURE 5-18 Built-in actions in the

Choose an action dialog box

The Condition action is one way to

create branching actions in the Power
Automate flow; another is the Switch
action, which is a conditional action
that determines which of multiple
cases to execute based on the input
fed to the switch. The advantage of the
Switch action over the Condition
action is that though Condition is
limited to two branches (Yes and No),
the Switch action can have as many
cases as are needed.

For example, the flow in Figure 5-19

contains an action that determines the
day of the week, which is then
followed by a Switch action that
contains cases named for days of the
week. Each case can then contain
actions specific to that day.

FIGURE 5-19 The Switch action with

three cases

Looping flows

Looping refers to flows that contain

sequences of actions that intentionally
repeat. Two of the most common
looping actions are Apply to each and
Do until. Each of these actions
performs a series of tasks repeatedly,
until a particular condition causes the
loop to end.

Apply to each is a loop action that

retrieves an array of items (such as
the 10 most recent emails received)
and performs a subsequent action (or
series of actions) on each of the items
in the array. For example, the flow
shown in Figure 5-20 first executes
the Get emails (V3) action to retrieve
the user’s ten most recent emails.
Then, the Apply to each action
executes the Condition action for the
10 emails, checking the value of the
Importance field in each one. If an
email is set to high importance, the
Send me a mobile notification action
executes; if not, then there is no
further action. The looping action
continues until all the items in the
array have been processed.
 ​

FIGURE 5-20 The Apply to each

action with a Condition action inside
the loop

Do until is a loop action that

repeatedly performs a subsequent
action (or series of actions) until a
specified condition is met. For
example, the flow in Figure 5-21 sets a
variable to an integer value of 1. Then,
the Do until action sets the loop to
repeat until the variable reaches a
value of 10. The Increment variable
action within the Do until loop
increases the variable by 1 each time it
executes. The loop repeats until the
value of the variable reaches 10.

FIGURE 5-21 The Do until action

with an Increment variable action
inside the loop

Describe expressions

Power Automate provides a large

collection of connectors with a wide
selection of triggers and actions. Most
of the triggers and actions have
settings that the developer must
configure before the flow will operate.
Placing the mouse cursor in a text box
causes a Dynamic content pop-up to
appear.

This dialog box contains fields from

the data source accessible by the
connector. Selecting a field inserts a
variable into the text box that is
replaced by actual data when the flow
executes. For example, selecting the
Timestamp field inserts the
Timestamp variable into the text box,
as shown in Figure 5-22. When the
flow runs, the variable will be replaced
by the time stamp reflecting the date
and time that the flow executed.

FIGURE 5-22 The Dynamic content

pop-up dialog box with the
Timestamp field selected

However, there are instances when

developers might want to add
operations that are not provided by an
action’s native settings. For these
cases, Power Automate supports the
use of expressions, which can perform
operations on existing values.

The previous example used the Get

calendar view of events (V3) action
and inserted the Timestamp variable
into the Start Time text box. The
action will therefore get the calendar
events starting on the date and time
the flow is executed. For the End Time
value, the developer might want to get
seven days’ worth of calendar
information. The field could accept an
exact date and time, in the correct
time stamp format, but this does not
provide a permanent solution for the
flow.

Instead, the developer can insert the

addDays() expression, which can
calculate an end time seven days from
the date and time that the flow is
executed. Selecting the Expression tab
on the pop-up menu displays a list of
expressions that can perform a variety
of operations. The addDays()
expression, as shown in Figure 5-23,
takes as its parameters the time stamp
from which the days will be added and
the number of days to add (or
subtract, using a negative value).

FIGURE 5-23 The Expression tab in

the pop-up dialog box, with the
addDays() expression selected

For the purpose of this example, the

value for the End Time field will be as
follows:

addDays (utcNow(),7)

The utcNow() expression returns the

time stamp for the current date and
time, so the addDays() expression will
take the date and time when the flow
executes and add seven days to it.
Other date and time expressions allow
developers to add hours, minutes, or
seconds to a given time.

Expressions can perform many other

functions apart from working with
time stamps. The expressions that
Power Automate uses are taken from
the Workflow Definition Language in
Azure Logic Apps and are organized
into the following categories:

■ String functions—Manipulate data strings by concatenating, replacing,

splitting, trimming, formatting, and converting data

■ Collection functions—Work with data arrays by specifying their length,

locating empty strings, joining elements, and locating their first or last
elements

■ Logical functions—Perform calculations using if/then statements,

arithmetical functions, and Boolean operators

■ Conversion functions—Convert input to different data types, such as

integers, strings, Booleans, and XML or JSON values

■ Math functions—Perform standard arithmetical functions, generate

random values, and identify minimum and maximum values

■ Date and time—Generate strings containing time stamps based on

calendar functions, such as adding and subtracting time intervals and
identifying the start of a time interval

■ Referencing functions—Provide the ability to work with the inputs and

outputs of other triggers and actions

■ Workflow functions—Provide the ability to retrieve details about a

flow and the URL of a trigger or action

■ URI parsing functions—Retrieve specific information about URIs,

including host names, queries, paths, ports, and schemes

■ Manipulation—Retrieve information about and modify JSON and

XML objects

Need More Review? Expressions

For a schema reference guide

to the Azure Logic Apps
Workflow Definition Language
that contains expressions
usable in Power Automate, see
https://docs.microsoft.com/en
-us/azure/logic-apps/logic-
apps-workflow-definition-
language?

Describe approvals

One of the common uses of Power

Automate flows is to process
approvals of documents in which
users must seek the approval of a
superior before the task they are
working on is completed. For
example, a file might require approval
before it can be posted to a SharePoint
site, or an email might require
approval before a user can send it out
to customers.

In many cases, an approval works by

having users post documents to a
temporary place, such as a SharePoint
list. The temporary post triggers a
flow, which contains an Approvals
action. This action generates an
approval request email and sends it to
a designated user, as shown in Figure
5-24. An approval tile also appears on
the user’s Home page of the Power
Automate portal. The user responds
by approving or rejecting the
document, and a Condition action
takes appropriate action depending
on the response.

FIGURE 5-24 An approval email

generated by an Approvals action

In the example flow shown in Figure

5-25, users wanting to send an email
to the organization’s customers post
the desired text in a SharePoint list
called CustomerMail. This triggers the
flow, which runs a Start an approval
action, specifying the name of the
person whose approval is sought and
containing a link to the SharePoint
item.

FIGURE 5-25 An example of an

approval flow

When the approver’s response is

returned to the flow, the Start an
approval action passes it down to a
Condition action, which tests for a
value of Yes in the Response field. In
the If yes branch of the condition are
actions that update the SharePoint
item to register its approval and
generate the email message for the
customers. In the If no branch, there
is just an Update item action that
registers the No response in the
SharePoint item.

SKILL 5.2: BUILD A BASIC FLOW

Power Automate provides two basic

ways of creating a flow: one is to select
from the many templates included
with the tool, and the other is to start
from scratch by selecting a trigger
type and adding actions from there.
The Home page in the Power
Automate portal, shown in Figure 5-
26, provides several entries into these
two methods.

FIGURE 5-26 The Home page in the

Power Automate portal

The search box at the top of the screen

allows users to locate templates and
other elements related to their needs.
Then, there are several collections of
templates directed toward specific
business needs, such as those aimed
at sales, information, and productivity
tasks. The next element is a list of
icons for popular services, such as
SharePoint and Office 365 Outlook,
which provide developers with
triggers, templates, and actions for
those services. All of these are entries
to the same process of creating and
modifying flows.

This skill covers how to:

■ Create a flow by using the button, automated, or scheduled flow

template

■ Modify a flow

■ Use flow controls to perform data operations

■ Run a flow

Create a flow by using the button,

automated, or scheduled flow template

The Create page in the Power

Automate portal, shown in Figure 5-
27, also provides different methods
for creating a flow. The first method is
to start from a blank flow by selecting
one of the tiles representing the type
of trigger that will launch it.

FIGURE 5-27 The Create page in the

Power Automate portal

Selecting one of these three tiles

opens a screen containing
configuration settings for the trigger,
as shown in “Identify flow types,”
earlier in this chapter. These screens
function as follows:

■ Automated flow—To create an automated flow, the developer must

select a trigger that monitors some element of a connector for activity
that launches the flow. For example, the trigger can launch the flow in
response to the arrival of a message or the creation of a document in an
application or service.

■ Instant (also called button) flow—To create an instant (or button)

flow, the developer must select a trigger that responds to an action by the
flow user. The trigger can be linked to a button pressed in the Power
Automate mobile app or an activity in another application or service,
such as selecting a file or other object.

■ Scheduled flow—To create a scheduled flow, the developer must

specify a date and time for the flow to launch and, if necessary, a repeat
interval.

■ UI flow—To create a UI flow, the developer only has to specify a name

for the flow.

■ Business process flow—To create a business process flow, the

developer must select the entity in which the information gathered from
the user by the flow will be stored.

Exam Tip
 Candidates for the PL-900 exam
should be conscious of the fact
that the button flow type
referenced in the exam objective is
now referred to as the instant flow
type in the Power Automate
portal.

In the case of the automated, instant,

and scheduled flows, the opening
screen specifies how and when the
flow will launch. The UI and business
process flows have specialized
functions that will be deliberately
launched by the users.

Using the Power Automate workspace

canvas

After the developer has configured the

trigger for an automated, instant, or
scheduled flow in the Power Automate
portal, the workspace canvas for the
flow appears, as shown in Figure 5-28.
In this example, an automated flow is
triggered each time a new email
arrives at the user’s Outlook 365
Inbox. By default, the trigger uses the
account of the user that is currently
logged on, although it is possible to
create a new connection to a different
email address, if desired.

FIGURE 5-28 A trigger in a Power

Automate flow

With the trigger in place, the

developer can then click the New step
button to open the Choose an action
dialog box, as shown in Figure 5-29.
Power Automate provides hundreds of
actions that developers can use to
manage the incoming email messages.
For example, Control actions can
evaluate the email messages and take
action on what they find. Notification
actions can inform the user when
certain types of emails arrive. This
example will use both of these action
types.

FIGURE 5-29 The Choose an action

dialog box in a Power Automate flow

Selecting the Condition action adds

three boxes to the workspace canvas,
as shown in Figure 5-30: the
Condition box and, branching from
that, an If yes and an If no box.

FIGURE 5-30 A Condition action in

a Power Automate flow

In the Condition box, the developer

creates an if/then statement that can
examine some part of the incoming
email. Clicking in the Choose a value
text box opens the Dynamic content
pop-up, as shown in Figure 5-31,
which lists the various fields in an
email.
 ​

FIGURE 5-31 The Dynamic content

pop-up in a Power Automate flow

The Condition box can test the value

of any field in the email and return a
Yes or No response. For example,
after selecting the Importance field,
the developer can type one of the
acceptable values for that field in the
Choose a value box. In this example,
the condition being tested is whether
Importance is equal to high, as shown
in Figure 5-32. In the same way, the
developer could use the Condition box
to test whether the From field
contains the name of a specific person
or the Subject field contains a specific
text string.

FIGURE 5-32 A Condition equation

in a Power Automate flow

The If yes and If no boxes take action

based on the results of the equation in
the Condition box. If an email is set to
have high importance, the Condition
result is yes, and the flow executes any
actions in the If yes box.

Clicking Add an action in the If yes

box opens the same Choose an action
dialog box shown earlier. In this
example, high importance emails
cause the flow to execute the Send me
a mobile notification action, as shown
in Figure 5-33. The developer can type
any message in the Text box and
include values from fields selected in
the Dynamic content pop-up. In this
case, the notification will specify the
sender of the email.

FIGURE 5-33 A Send me a mobile

notification action in the If yes box in
a Power Automate flow

The developer can create additional

actions in the If yes box, if desired,
such as an action that stores the email
in a SharePoint site or copies any
attachments to the user’s OneDrive.
The If no box can contain actions also,
or be left blank, as needed.

Once the flow is complete, the

developer should click Save to make
sure that the flow is added to the
user’s My flows list, as shown in
Figure 5-34.

FIGURE 5-34 A new flow in the My

flows list in Power Automate

Modify a flow

For many new developers, the easiest

way to learn how to build a flow is to
begin with one of the flow templates
included with Power Automate. A
template includes the trigger and all
of the actions needed to complete the
flow’s designated tasks, although
some configuration of the elements
might be needed to render the flow
fully operational.
Many of the Power Automate flow
templates are designed to transfer
data from one application or service to
another. For example, the Copy files
between OneDrive for Business and
SharePoint template, shown in Figure
5-35, creates an automated flow that
monitors a specified OneDrive folder
and copies all the files saved there to a
specific SharePoint folder. The flow
also checks for the success of the copy
operation and generates an email if it
fails.

FIGURE 5-35 The Copy files

between OneDrive for Business and
SharePoint flow template tile

A template such as this one needs

some modification before it can run.
The developer must specify which
OneDrive folder the trigger should
monitor and choose the SharePoint
site and the folder on it where the
incoming files will be stored. The
template detail screen, shown in
Figure 5-36, includes drop-down lists
in which the developer can configure
the necessary fields.
 ​

FIGURE 5-36 The Copy files

between OneDrive for Business and
SharePoint flow template detail
screen

The template also provides a list of the

connectors the flow will use, which
the developer can modify to use
different credentials as needed. The
flow then appears in the Power
Automate workspace canvas, as
shown in Figure 5-37.

FIGURE 5-37 The workspace canvas

for the Copy files between OneDrive
for Business and SharePoint flow
template

In this template, the flow’s trigger

monitors the specified OneDrive
folder and, when files appear in it, the
SharePoint Create file action uses the
OneDrive File name and File content
values to copy the files to the specified
SharePoint folder. Then, a Condition
action checks the status code of the
SharePoint file creation and, if the
value is 403 (Forbidden), the If yes
branch generates an email to the user
indicating that the task has failed.

Once the workspace canvas appears

with the specified OneDrive and
SharePoint folders, the work of the
template is complete. The trigger and
actions shown on the canvas are no
different than if the developer created
the flow from scratch. This means that
it is possible for the developer to
modify the flow as needed by
changing the existing actions,
inserting new actions, or altering the
order in which the actions are
executed.

Modifying actions

Whether created by a template or

added manually, developers can
always modify the configuration of a
trigger or action. By default, triggers
and actions use the currently logged-
on user’s account to establish a
connection to an application or
service. Clicking the menu button in
the trigger or action displays a context
menu with a My connections section,
as shown in Figure 5-38, in which the
developer can select a different user
account or add a new connection.

FIGURE 5-38 The context menu for

a SharePoint Create file action

When the developer changes the

connection to use a different account,
the drop-down lists and the Dynamic
content fields for the action change as
well. In this example, the Site address
and Folder path fields have drop-
down lists that provide access to the
current user’s SharePoint
environment. Changing the user
address for the connection changes
the contents of the drop-down lists.
The File name and File content values
are dynamic content fields that
reference the OneDrive connection
established in the trigger, so changing
the connection in the trigger above
changes the fields available in the
Dynamic content pop-up.

Inserting actions

Developers can add actions to a flow

in multiple ways. The Power
Automate workspace canvas always
includes a +New step button at the
bottom, which opens the Choose an
action dialog box. Selecting an action
from the dialog box adds it to the
bottom of the flow. The arrows
pointing down from the trigger to the
first action and from one action to
another display a plus sign when the
cursor hovers over them, allowing a
developer to insert an action between
two existing steps. Clicking the plus
sign displays a menu with two
options:

■ Add an action—Opens the Choose an action dialog box, in which the

developer can select an action to be inserted between the existing steps

■ Add a parallel branch—Opens the Choose an action dialog box in a

separate branch off of the step above, as shown in Figure 5-39. This
allows the flow to perform two separate actions at the same time, both
using the results of the same previous step.

FIGURE 5-39 Two actions in a

parallel branch off of a single trigger

Note Dragging and Dropping Actions

The trigger step always

 appears at the top of a flow,
with one or more action steps
beneath it. When a flow runs,
it executes the steps from top
to bottom. The workspace
canvas uses down-pointing
arrows to indicate the
progression between steps.
When editing a flow, however,
the developer can modify the
progression of the steps by
dragging and dropping actions
up or down as needed. This
alters the order in which the
running flow processes the
actions.

Use flow controls to perform data

operations

When working with data from various

sources, it is sometimes necessary to
modify the data format to make the
sources compatible. Power
Automate’s Data Operation actions
makes it possible to reuse and
reformat the data from previous
actions in various ways:

■ Compose—Allows the developer to type a data string into the Inputs

field, as shown in Figure 5-40, and reuse that string later. In a subsequent
action, the developer can select the Outputs field from the Compose
section in the Dynamic content pop-up to insert the string from the
Inputs field in the Compose action.

FIGURE 5-40 The Compose action

in the Power Automate workspace
canvas

■ Create CSV table—Allows the developer to convert a data array into a

table in CSV (comma-separated values) format, as shown in Figure 5-41.
In this example, the array of usernames taken from the body of the
previous action will be reformatted into the following table:

FIGURE 5-41 The Create CSV table action in the Power Automate
workspace canvas

Click here to view code image

FirstName,LastName​
Sanjay,Patel​
Joanna,Yuan
 ■ Create HTML table—Allows the developer to convert a data array into
an HTML (Hypertext Markup Language) table.

■ Filter array—Allows the developer to apply a filter to a data array

using an equation to select specific entries, as shown in Figure 5-42. In
this example, an array consisting of usernames will be filtered to include
only those users with a last name of Patel.

FIGURE 5-42 The Filter array action in the Power Automate workspace
canvas

■ Join—Allows the developer to modify a data array to use a different

delimiter, as shown in Figure 5-43. In this example, the array of
addresses in the From field is delimited by commas. Specifying a
semicolon in the Join with field ensures that the resulting output will be
the same array but delimited with semicolons.

FIGURE 5-43 The Join action in the Power Automate workspace canvas

■ Parse JSON—Allows the developer to interpret the JSON output from

a previous action by specifying a sample schema, as shown in Figure 5-
44. The developer can then use the Dynamic content pop-up for a
following action to select specific Parse JSON fields derived from the
sample schema.

FIGURE 5-44 The Parse JSON action in the Power Automate workspace
canvas

■ Select—Allows the developer to reshape a data array to suit a different

application or service, as shown in Figure 5-45. In this example, an array
of names using the labels first and last, such as [ { "first":
"Sanjay", "last": "Patel" }, { "first": "Joanna",
"last": "Yuan" } ], will be remapped to use the labels FirstName
and LastName instead, as in [ { "FirstName": "Sanjay",
"LastName": "Patel" }, { "FirstName": "Joanna",
"LastName": "Yuan" } ].

FIGURE 5-45 The Select action in the Power Automate workspace

canvas

Run a flow

After the developer has finished

building a flow and has saved it so
that it appears in the My flows list, it
is ready to run, based on the type of
trigger it uses. An automated flow will
run when the event specified in the
trigger occurs. An instant flow will run
when a user deliberately triggers it by
tapping a button or selecting an item.
A scheduled flow will run when the
specified date and time arrive.

To test a flow and examine how each

step executes, the developer can click
the Test button at the upper right of
the workspace canvas. This opens a
Test Flow pane, which provides
options for starting the flow by
performing the trigger action
manually, using the data from
previous runs, as shown in Figure 5-
46, or using data selected from the
trigger application, in this case
OneDrive for Business.

FIGURE 5-46 The Test Flow dialog

box in the Power Automate portal

After the test run begins, the

developer can monitor the
performance of each step on the
screen. Successfully executed steps
have a circled check mark and failed
steps have an X. Expanding each
completed step in the flow displays
detailed input and output information
for that step, as shown in Figure 5-47.
 ​

FIGURE 5-47 Flow test run results

For a step that has failed, an error

message appears describing the
reason for the failure, as shown in
Figure 5-48. In this example, the
Condition action exists only to send
an email to the user in the event that
the SharePoint Create file action fails.
The Create file action was successful
in this case, so despite the Condition
action having failed, the overall
execution of the flow is shown as
having succeeded.

FIGURE 5-48 Flow test run results

with a failed action

CHAPTER SUMMARY
■ Power Automate supports five flow types: automated, instant,
scheduled, UI, and business process.

■ To simplify the process of getting started in creating Power Automate

flows, the tool also includes dozens of templates.

■ Power Automate uses connectors to access data sources in flows for

both triggers and actions.

■ A flow can contain a condition, which is an if/then statement that

defines two possible actions. Looping refers to flows that contain
sequences of actions that intentionally repeat.
 ■ Power Automate supports the use of expressions, which can perform
operations on existing values.

■ One of the common uses of Power Automate flows is to process

approvals of documents, in which users must seek the approval of a
superior before the task they are working on is completed.

■ One method of creating a flow is to start from a blank flow by selecting

one of the tiles in the Power Automate portal representing the type of
trigger that will launch it.

■ For many new developers, the easiest way to learn how to build a flow
is to begin with one of the flow templates included with Power Automate.
Templates often need some modification before they can run.

■ Power Automate’s Data Operation actions make it possible to reuse

and reformat the data from previous actions in various ways.

■ To test a flow and examine how each step executes, the developer can
click the Test button at the upper right of the workspace canvas.

THOUGHT EXPERIMENT

In this thought experiment,

demonstrate your skills and
knowledge of the topics covered in
this chapter. You can find answer to
this thought experiment in the next
section.

Ralph is working with a British

application that stores customer
names using the labels Christian
Name and Surname. He wants to use
a Power Automate flow to transfer
data from the British application’s
database to an American customer
service application each time a new
customer record is created. However,
the American application refers to the
same customer name data fields as
First Name and Last Name. There are
connectors available for both
applications. Based on this
information, respond to the following
questions and describe the structure
of the required flow.

1. 1. How can Ralph reconcile the differently named data fields for the
two applications?

2. 2. How can Ralph transfer the customer names obtained from one
application to the other?

THOUGHT EXPERIMENT
ANSWERS

This section contains the solution to

the thought experiment. Each answer
explains why the answer choice is
correct.

1. 1. The flow should use the connector for the British application as the
trigger, launching the flow each time a new customer record is
created. After the trigger, add a Select action with the output from the
 trigger placed in the From field and Map values that equate the labels:
Christian Name with First Name and Surname with Last Name.

2. 2. After reconciling the data field names, Ralph should add an action
for the American application using the output from the Select action
as input.
Chapter 6

Demonstrate the
capabilities of Power
Virtual Agents
Power Virtual Agents is the most
recent addition to the Power Platform
toolkit; it allows developers to create
chatbots that provide customer
service functionality without having to
write code. A chatbot is a pop-up
window that appears on a user’s
screens and provides a realistic
dialogue experience with the
consumer, furnishing genuine
responses to customer service queries
and even taking action at the
customer’s request.

Skills covered in this chapter:

■ 6.1: Describe Power Virtual Agents capabilities

■ 6.2: Build and publish a basic chatbot

SKILL 6.1: DESCRIBE POWER

VIRTUAL AGENTS CAPABILITIES

Chatbots have long been seen as a

useful and economical means of
providing customer service, but the
development process involved in
creating them was often lengthy and
troublesome. This was, in large part,
because of the constant
communication required between the
development and customer service
departments, both prior to and
subsequent to the deployment of the
bot. Power Virtual Agents, by virtue of
its no-code or low-code development
requirements, allows the customer
service personnel themselves to create
chatbots and update them as needed
when circumstances change.

This skill covers how to:

■ Describe use cases for Power Virtual Agents

■ Describe where you can publish chatbots

■ Describe topics, entities, and actions

Describe use cases for Power Virtual
Agents

Customer service and first-tier

technical support services are always
expensive propositions. This cost can
be particularly galling for
organizations when so many of the
customer issues are simple and
repetitive that it does not seem worth
paying live representatives to give the
same answers over and over. Live
support can also be frustrating to
customers when they discover that the
hours they can interact with a live
person are limited or that they must
wait in a queue for the next available
representative.

Chatbots were created to take over

these repetitive and time-consuming
tasks from live telephone and chat
personnel. A bot with a script
designed to provide basic information
to customers can answer the simple
questions at any time of the day or
night, leaving the more complicated
issues to the live representatives.

Citizen developers

As time has passed and the value of

chatbots has been recognized by more
organizations, the bots have been
enhanced to take on more complex
tasks themselves, even using artificial
intelligence (AI) to perform actions
instead of just supplying information.
One of the main problems with these
increasingly complex chatbots is that
they require an extensive
development effort.

In a chatbot development project, a

gap has always existed between the
people who know what tasks the bot
has to perform and those who know
how to make the bot do them. This
gap is particularly problematic for
organizations in which the customer
service and technical support
requirements change frequently. One
of the primary design objectives for
Power Virtual Agents, as with the
other Power Platform tools, is to
reduce that gap by making it possible
for the customer service and technical
support people to function as citizen
developers by creating and updating
the chatbots themselves.

Power Virtual Agents provides a

guided graphical development
environment that allows these citizen
developers to create chatbots by
specifying the questions most
commonly asked by customers and
then supplying possible answers to
the questions. This strategy allows the
bot to lead the customers through a
branching dialog, such as that shown
in Figure 6-1, which leads them to a
satisfactory answer to their question.

FIGURE 6-1 A branching dialog in a

Power Virtual Agents chatbot

The Power Virtual Agents

development interface allows the
personnel familiar with customers’
questions to program the bot with
appropriate responses that they
themselves would otherwise supply.
More important, when the questions
change or new questions arise, these
same people can modify the bot to
accommodate the organization’s
changing needs. In other
environments, updating a bot can
require a lengthy period of latency as
the software goes back to a developer
for changes to the code, retesting, and
redeployment.

Artificial intelligence

The ultimate goal of any chatbot is to

make the customers believe that they
are conversing with a real person.
That might or might not be possible,
depending on the effort put into the
bot’s development and on the
sophistication of the customer, but
Power Virtual Agents includes AI
capabilities that allow it to engage the
customer in realistic exchanges.

For example, the phrases that the

developer supplies—the phrases that
the customer can use in the
conversation with the bot—might
include “help me,” “I need help,” and
many others. However, there are any
number of other variations that a
customer might also use, which the
developer could not possibly
anticipate. By supplying Power Virtual
Agents with a selection of common
phrases, it uses AI to extrapolate
others and accommodate many of the
alternatives that customers might
supply.

Taking action

Because it is part of the Power

Platform toolkit, Power Virtual Agents
can also work in conjunction with the
other tools. The same connectors that
allow Power Apps and Power
Automate to interact with outside
applications and services are available
to Power Virtual Agents as well. This
allows chatbots to not just dispense
prerecorded information, but also to
perform actions in response to
customer requests by calling flows or
apps and connecting to external data
sources.

Exam Tip

Candidates for the PL-900 exam

should be conscious of the
warnings that Microsoft includes
with the Power Virtual Agents
documentation, specifying that the
product is not intended for use in
emergency situations or for
diagnosing or treating medical
conditions, and that Microsoft
abjures all responsibility for
situations arising from the use of
chatbots created by Power Virtual
Agents subscribers.

Describe where you can publish chatbots

Publishing a chatbot makes it

available to consumers. Whenever
developers make changes to chatbots,
they must republish them for
consumers to see those changes.
When a developer publishes a chatbot
for the first time, Power Virtual
Agents makes it available for testing
on a demo website, as shown in Figure
6-2.

FIGURE 6-2 Demo website for

Power Virtual Agents

Arguably, the place where consumers

are most likely to encounter chatbots
is on websites, but developers can
publish their chatbots to many types
of platforms other than websites,
including internal messaging
platforms, such as Microsoft Teams;
mobile apps; and social media. Power
Virtual Agents refers to these places of
publication as channels, some of
which are shown in the Power Virtual
Agents portal, as shown in Figure 6-3.

FIGURE 6-3 The Channels page in

the Power Virtual Agents portal

Need More Review? Channels

For a complete list of the

channels supported by Power
Virtual Agents, expand the
Manage menu item in the
navigation pane of the Power
Virtual Agents portal and
select Channels.

Developers can publish a single

chatbot to more than one channel.
When a developer publishes a chatbot
to multiple channels, modifying the
bot and republishing it causes it to be
refreshed on all the channels in which
it appears.

Describe topics, entities, and actions

A chatbot has to understand what the

user is saying and react appropriately,
even when the user says something
unexpected. Power Virtual Agents
uses elements such as topics, entities,
and actions to do this.

Topics

Power Virtual Agents simplifies the

process of creating and configuring a
chatbot by breaking the conversation
between the bot and the user down
into discrete elements called topics.
For example, the first topic for a
chatbot might be a greeting that
welcomes the user and introduces the
bot’s purpose. The Topics page in the
Power Virtual Agents portal, shown in
Figure 6-4, contains a selection of
basic system topics and also allows
the developer to create new ones from
scratch.

FIGURE 6-4 The Topics page in the

Power Virtual Agents portal

As noted earlier, a topic begins with a

trigger phrase, which is a list of
possible phrases that the user might
supply, which the bot understands
and uses to initiate a particular
conversation topic. The greeting topic,
for example, might include “Hi,”
“Hello,” and “Good morning” in its list
of trigger phrases.

A conversation will typically span

multiple topics, with the bot
configured to launch a specific new
topic based on the user’s responses to
the bot’s questions. For example, at
the end of the greeting topic, the
developer might have the bot ask the
user to specify the product with which
they are experiencing a problem.
When the user responds with a
product name, as shown in Figure 6-5,
the developer can select Go to another
topic and link to a topic specific to
that product.
 ​

FIGURE 6-5 Linking topics

Entities

In Power Virtual Agents, the term

entity has a different meaning than it
does in the Common Data Service. An
entity in Power Virtual Agents is
essentially a dictionary of terms and
phrases that a bot’s artificial
intelligence uses to identify a concept
in a conversation. This aids the bot in
understanding what the user is saying,
even when the language the user
employs is not an exact match to one
of the trigger phrases in the topic’s
list.

Need More Review? Entities

For more information on

entities, see the “Describe
entities, fields, and
relationships” section in
Chapter 2, “Identify the Core
Components of Power
Platform.”

The Entities page in the Power Virtual

Agents portal, shown in Figure 6-6,
contains a list of prebuilt entities that
help bots to understand many
common conversational concepts.
These entities provide examples of
syntax for these concepts that help the
bot to understand what the user is
saying.

FIGURE 6-6 The Entities page in the

Power Virtual Agents portal

For example, there are many ways

that users can reference specific dates
or times in conversation. The user
might refer to “last Thursday,” or
“December 25,” or “3pm,” all of which
are easily comprehensible to another
person but are not understandable to
a bot unless it has some frame of
reference for those expressions. The
Date and time entity, shown in Figure
6-7, contains examples of these
expressions and provides translations
into saved values, which are time
stamps that the bot can understand.

FIGURE 6-7 The Date and time

entity

The prebuilt entities included with

Power Virtual Agents provide bots
with standard business terminology,
but some organizations require bots
to handle conversations involving
specialized vocabulary. To
accommodate these needs, developers
can create custom entities using the
interface shown in Figure 6-8, in
which they can specify terms and
synonyms by which users might refer
to them.

FIGURE 6-8 The entity creation

interface

To use an entity when configuring a

bot to ask a question, a developer
selects the appropriate entity in the
Identify selector, as shown in Figure
6-9.

FIGURE 6-9 Using an entity in a bot

Actions

An action, as the word implies, is an

element that allows a Power Virtual
Agents bot to actually do something
beyond conversing with the user.
When a developer creates a new node
in the Power Virtual Agents
workspace, as shown in Figure 6-10,
selecting Call an action provides the
option to authenticate the user with
an identity provider, such as Azure
Active Directory, or create a flow
using Power Automate.

FIGURE 6-10 Calling an action from

a bot in Power Virtual Agents

A bot can call an existing flow as long

as it exists in the same environment
as the bot, or the developer can create
a new flow from scratch. By working
in tandem with Power Automate, a
Power Virtual Agents chatbot can
perform a wide variety of tasks to
service the user, including retrieving
information from a database or
service.

Note Bot and Flow Interaction

Power Automate flows can

interact with Power Virtual
Agent bots by exchanging data.
To relay information to and
from a data source using a
flow, Power Virtual Agents
creates variables that the
developer can then use
elsewhere in the topic.

SKILL 6.2: BUILD AND PUBLISH

A BASIC CHATBOT

Power Virtual Agents simplifies the

process of creating chatbots by
eliminating the need to write code and
providing a graphical design interface.
The following sections examine the
steps involved in creating and running
a chatbot.
 This skill covers how to:

■ Create a chatbot

■ Create a topic

■ Call an action

■ Test a chatbot

■ Publish a chatbot

■ Monitor chatbot usage

■ Monitor chatbot performance

Create a chatbot

After starting Power Virtual Agents, a

developer must begin by creating a
bot, using the dialog box shown in
Figure 6-11. This step involves
selecting a name, a language, and the
environment in which the bot will be
created. The process by which Power
Virtual Agents creates the account’s
first bot occurs in the background and
can take as long as 15 minutes.

FIGURE 6-11 The Create a new bot

dialog box

To create additional bots, developers

must click the Bots panel icon at the
top-right corner of the Power Virtual
Agents portal to open the Bots panel
shown in Figure 6-12 and then click
the + New bot button.
 ​

FIGURE 6-12 The Bots panel in the

Power Virtual Agents portal

Create a topic

As noted earlier, Power Virtual Agents

includes a collection of system topics
that cover some of the most common
exchanges between bots and
customers. When first creating a bot,
a developer might want to use the
Greeting topic to start the
conversation, but after that,
developers might have to create topics
from scratch to accommodate their
business needs.

The prebuilt Greeting topic ends with

a message node saying “So, what can I
help you with today?” Therefore, the
next topic should address the possible
responses that the customer might
supply to that question. After creating
that new topic, the developer can then
link it to the Greeting topic to create a
conversation by clicking the plus sign
and selecting Go to another topic, as
shown in Figure 6-13.

​
FIGURE 6-13 Linking to another
topic

To create a new, blank topic, the

developer clicks the +New topic
button on the Topics page to open the
panel shown in Figure 6-14. After
supplying a name for the topic, and
optionally a description, the developer
can proceed to create a list of trigger
phrases. These phrases should be the
most likely responses to the question
the bot asks at the end of the Greeting
topic.

FIGURE 6-14 The +New topic

interface in the Power Virtual Agents
portal

For this example, Request might be an

appropriate title, and some possible
trigger phrases would be as follows:

■ I want to check the status of an order

■ I want to return a product

■ I want to place an order

After saving the topic, clicking the Go

to authoring canvas button adds the
phrases to the Trigger Phrases node,
along with an empty Message node.
The developer can add a message and
then click the plus sign under the
Message node to add another node.
For example, the developer could
select the Ask a question option and
use it to provide the customer with
three choices, as shown in Figure 6-
15.
 ​

FIGURE 6-15 Building a topic in the

Power Virtual Agents workspace

The Question node allows the

developer to branch the conversation
by creating three conditions
corresponding to the three trigger
phrases. The developer can then
develop the branch for each option
separately to complete the desired
task.

Call an action

In the example presented here, the

three options presented to the
customer might require the bot to do
more than just provide prerecorded
information. As mentioned earlier in
this chapter, Power Virtual Agents can
also perform actions by working
together with Power Automate. It is
actually Power Automate flows that
perform actions, but a Power Virtual
Agents bot can pass information to a
flow and receive information back
using variables.

So, for example, if a customer

requests the status of an order, the bot
can request an order number from the
customer and save it to a variable, as
shown in Figure 6-16.
 ​

FIGURE 6-16 Assigning bot user

input to a variable

When the developer clicks the plus

sign to add a node and selects Call an
action, the option Create a flow
appears. This option opens the Power
Automate portal in a separate window
and loads the Power Virtual Agents
Flow Template, as shown in Figure 6-
17.

FIGURE 6-17 Power Virtual Agents

Flow Template in Power Automate

The developer can then build a flow in

Power Automate, using the variable
created by the bot, which appears in
the Dynamic content window, as
shown in Figure 6-18, to query a
database and retrieve the order status.
The flow can then pass the order
status it has discovered back to the
bot using a variable in the same way,
and the bot can furnish it to the
customer.
 ​

FIGURE 6-18 Adding a Power

Virtual Agents variable to a Power
Automate flow

Test a chatbot

In the lower-left corner of the Power

Virtual Agents portal is a Test your
bot button, which opens a test pane,
as shown in Figure 6-19. This pane
allows the developer to interact with
the bot as a customer while tracking
the progress of the conversation
through the nodes in the workspace.

FIGURE 6-19 Testing a bot

Acting as a customer, the developer

initiates the conversation with one of
the topic’s trigger phrases. As the test
conversation proceeds, each node that
is processed appears with a green title
bar and a circled check mark in the
top-right corner. If problems occur,
the developer can make changes in
the workspace and click the Reset
button at the top of the pane to begin
the conversation again.

Publish a chatbot

Developers can test their bots as they

create them using the testing pane,
but to run the bot on an actual website
and make it available to customers,
the developer must publish it. The
Publish page, shown in Figure 6-20,
contains a single Publish button that
makes the current version of the bot
available for distribution to users.

FIGURE 6-20 The Publish page in

the Power Virtual Agents portal

Note Republishing

In Power Virtual Agents,

publishing a bot is not usually
a one-time task. Developers
must republish their bots each
time they make changes to
them so that the latest version
is provided to users. The
channel on which a bot
appears will continue to use its
existing content until the bot is
republished, even when the
original conversation has been
modified in the Power Virtual
Agents portal.

Publishing a bot makes it available on

a demo website that is fully
operational, as shown in Figure 6-21.
The demo website is accessible to the
internet, but it is not intended to be
used as a production platform for the
bot.
 ​

FIGURE 6-21 Demo website with

functioning chatbot

As mentioned earlier in this chapter,

Power Virtual Agents publishes bots
to channels, and the demo website has
a channel tile of its own, which you
can configure by adding a welcome
message and suggested trigger
phrases, as shown in Figure 6-22.

FIGURE 6-22 The Demo website

panel

Publishing a chatbot to the demo

website is a simple process that occurs
wholly within Power Virtual Agents.
To publish a bot to another site on the
web, the Custom website channel
provides the HTML code needed to
embed the bot on a page, as shown in
Figure 6-23. Because the embed code
calls the bot from the Power Virtual
Agents service in the cloud, its content
is updated whenever the developer
republishes it.
 ​

FIGURE 6-23 The Custom website

panel

Publishing a bot to other channels can

require different procedures, based on
the platform with which the developer
is working. It might be necessary for
the bot developer to work with other
administrators within the company to
obtain the necessary permissions to
add a bot to a platform such as Teams
or the credentials necessary to
manage a company social media
account. The tiles for the various
channels provide links to instructions
for embedding bots in various
services, as well as a Bot ID and
Tenant ID that uniquely identify the
developer’s tenancy and the specific
bot within that tenancy.

Monitor chatbot usage

The Analytics page in the Power

Virtual Agents portal, shown in Figure
6-24, provides an array of charts that
allow developers and administrators
to track the number of users that
access a bot and examine the results
of that usage.
 ​

FIGURE 6-24 The Analytics page in

the Power Virtual Agents portal

The top row of small area charts

provides the following statistics for
the range of dates specified in the
selector:

■ Total sessions—Specifies the number of bot sessions that took place

■ Engagement rate—Specifies the number of bot sessions in which the

user’s topic was found or the session was escalated

■ Resolution rate—Specifies the number of bot sessions in which the

user responded positively to a customer satisfaction survey

■ Escalation rate—Specifies the number of bot sessions that were

escalated to a human representative

■ Abandon rate—Specifies the number of bot sessions that were

engaged but not resolved or escalated

■ CSAT—Displays the results of the customer satisfaction survey the bot

provides to willing users at the end of the conversation

Monitor chatbot performance

Power Virtual Agents includes a

prebuilt End of Conversation topic,
shown in Figure 6-25, which includes
a survey question that allows users to
state whether their session with the
bot was successful in answering their
questions or solving their problems.
This is one way to monitor the
performance of a chatbot in terms of
customer satisfaction.

FIGURE 6-25 The End of

Conversation prebuilt topic in Power
Virtual Agents

The Analytics page includes charts

that track the customer survey results
generated by the End of Conversation
topic, as well as the other possible
session outcomes:

■ Engagement—A session in which the customer supplies a trigger

phrase that launches a user-created topic (as opposed to one of the
system topics, such as Greeting) or the session ends with the escalation of
the issue to a human representative. An engaged session must always be
resolved, escalated, or abandoned.

■ Resolution—An engaged session in which the user responds to the End

of Conversation customer satisfaction survey with Yes or with no answer.

■ Escalation—An engaged session in which the bot transfers the issue to

a human representative.

■ Abandonment—An engaged session that, after one hour elapses, is not

resolved or escalated.

Some of the more detailed charts

included on the Analytics page are as
follows:

■ Session outcomes over time—A line chart that tracks the daily number
of resolved, escalated, and abandoned sessions on separate colored lines.

■ Engagement over time—A column chart that specifies the daily

number of engaged and unengaged sessions.

■ Rate drivers—Three tables that lists the topics with the greatest
impact on the bot’s resolution, escalation, and abandonment rates. In
each table, the Rate figure is the percentage of engaged sessions,
including the specified topics that have a Resolved, Escalated, or
Abandoned outcome. Impact is a bar representing the resolution,
escalation, or abandonment rate of sessions, including the specified topic
minus the rate of sessions that do not include the topic. A red bar
indicates a greater-than-average resolution, escalation, or abandonment
rate; a blue bar indicates a less-than-average rate.

CHAPTER SUMMARY
■ Power Virtual Agents is a no-code or low-code tool that allows
customer service and technical support personnel themselves to create
chatbots and update them as needed.

■ Developers can publish chatbots to websites and many other types of

platforms, including internal messaging platforms, such as Microsoft
Teams, mobile apps, and social media. Power Virtual Agents refers to
these places of publication as channels.

■ Power Virtual Agents breaks down the conversation between a bot and
a user into discrete elements called topics. An entity is a dictionary of
terms and phrases that a bot’s artificial intelligence uses to identify a
concept in a conversation. An action is an element that allows a bot to
actually do something beyond conversing with the user.

■ After starting Power Virtual Agents, a developer must start by creating

a bot, which involves selecting a name, a language, and the environment
in which the bot will be created. The process occurs in the background
and can take as long as 15 minutes.

■ Power Virtual Agents includes a collection of system topics that cover

some of the most common exchanges between bots and customers.
Developers can also create their own topics from scratch.

■ Power Virtual Agents can perform actions by working together with

Power Automate. It is actually Power Automate flows that perform
actions, but a bot can pass information to a flow and receive information
back using variables.

■ The test pane allows the developer to interact with the bot as a
customer while tracking the progress of the conversation through the
nodes in the workspace.

■ The Publish page contains a single Publish button that makes the
current version of the bot available for distribution to users. Developers
must republish their bots each time they make changes to them so that
the latest version is provided to users.

■ The Analytics page in the Power Virtual Agents portal provides an

array of charts that allow developers and administrators to track the
number of users that access a bot and examine the results of that usage.

■ Power Virtual Agents includes a prebuilt End of Conversation topic,

which includes a survey question that allows users to state whether their
session with the bot was successful in answering their questions or
solving their problems.
THOUGHT EXPERIMENT

In this thought experiment,

demonstrate your skills and
knowledge of the topics covered in
this chapter. You can find answer to
this thought experiment in the next
section.

Ralph is experimenting with the

Power Platform tools, and he has just
created a Power Automate flow for his
company’s technical support
department that allows a user to
create a new trouble ticket and submit
it for attention by the help desk.
However, the manager of the tech
support department is wary of the
help desk being inundated with
trouble tickets for trivial issues that
the users could conceivably resolve
themselves.

Ralph is now looking at the

capabilities of Power Virtual Agents,
and he wonders if he could use a
chatbot to provide users with basic
technical support in the form of
questions to which they must respond
before they are able to fill out a
trouble ticket. With the help of the
technical support manager, Ralph
compiles a list of questions that a help
desk representative would ask users
when they report some common
problems. The questions are phrased
so that “No” answers indicate a failure
to solve the problem.

Based on this information, answer the

following questions:

1. 1. How might Ralph design the chatbot’s conversation with the user?

2. 2. How might Ralph incorporate the Power Automate flow he created

into the bot’s conversation?

THOUGHT EXPERIMENT
ANSWERS

This section contains the solution to

the thought experiment. Each answer
explains why the answer choice is
correct.

1. 1. Ralph could create a topic containing a series of Question nodes

that attempt to isolate the user’s problem. “Yes” responses indicate
that the user is experiencing the proposed problem, and the bot could
provide information to help the user solve it.

2. 2. After a certain number of “No” responses, indicating that the

proposed problems have been ruled out, the conversation should
proceed to an Action node that calls the flow in Power Automate and
allows the user to fill out and submit a trouble ticket.
Index
NUMERICS

100% stacked charts, 96

AAD (Azure Active Directory), 32, 42,

45, 45, 59

actions, 76–78, 198

calling, 242–243

Compose, 222

Condition, 205

Create CSV table, 222–223

Create HTML table, 223

dragging and dropping, 222

Filter array, 223

inserting, 221–222

Join, 223

modifying, 220–221

Parse JSON, 223–224

Power Virtual Agents, 237–238

Select, 224

Activity entities, 60

addDays() expression, 209

admin centers, 47–48

Admin portal, Power BI, 49

aggregation, 126–128

AI (artificial intelligence), 230–231

AI Builder, 2, 83
business value, 83–84

consumption of data, 90–91

custom models, 89–90

prebuilt models, 83, 84

Business Card Reader, 84–85

Category Classification, 85–86

Entity Extraction, 85–86

Key Phrase Extraction, 87–87

Language Detection, 87–88

Sentiment Analysis, 87–88

Text Recognition, 88–89

alerts, Power BI, 8–9

ALM (application lifecycle

management), 68

Analytics menu, Power Platform, 48

APIs, and custom connectors, 80–83

approvals, 211–212

apps. See also canvas apps; Dynamics

365; model-driven apps; Power Apps

canvas, 13, 148, 150, 154

building, 161

creating, 148–149

screens, 148–150

Dynamics 365, 25, 26

help desk, 150

managing, 42

model-driven, 13, 150–152

adding entities to app navigation,
181–183

building, 180–181

forms, 185–186

views, 186–187

portal, 13, 152–153, 173

creating, 173–176

customizations, 176–178

themes, 179–180

user authentication, 179

Power, 13–15

Power BI, 6–7, 7

publishing, 172–173, 187–188

screens

detail, 169

edit, 170

gallery, 168

sharing, 172–173

storing data in Common Data Service,

58–59

template, 134–135

third-party, 30

using with Common Data Service, 59

area charts, 99

attributes, 15

auditing, 52–53

authentication, portal apps, 179

automated flows, 192

Azure, 32

admin centers, 47–48

Azure Blob, 37

Back-End cluster, 35–36, 37

bar and column charts, 95–98

bots. See also chatbots

actions, 237–238

entities, 235–237

flow interaction, 238

topics, 233–234

building

canvas apps, 161

connecting to data using connectors,

163–167

data sources, 161–163

starting with a blank app, 163–165

starting with a data source, 165–166

starting with a template, 167

dashboards, 135

flows, 212–224

model-driven apps, 180–181

Business Card Reader model, 84–85

business process flows, 19, 68–70, 194

business rules, 70–71

conditions, 70
business value, of AI Builder, 83–84

calling an action, 242–243

canvas apps, 13, 148, 150, 154

building, 161

connecting to data using connectors,

163–167

data sources, 161–163

starting with a blank app, 163–165

starting with a data source, 165–166

starting with a template, 167

creating, 148–149

screens, 148–150

sharing, 150

using with Common Data Service, 59

cards, 102

Category Classification model, 85–86

CDM (Common Data Model), 2,

71–72

folders, 73

schemas, 72

charts

100% stacked, 96

area, 99

clustered, 96–97

combo, 99

funnel, 97

gauge, 103
KPI, 102

line, 98

pie, 100

scatter, 101

stacked, 95–96

waterfall, 97–98

chatbots, 229, 230

calling an action, 242–243

creating, 22–23, 238–239

creating a topic, 240–242

monitoring

performance, 248–249

usage, 247–248

publishing, 232–233, 244–246

testing, 243–244

topics, 233–234

citizen developers, 1, 23, 29, 147

creating chatbots, 22–23

Power Virtual Agents, 230

classic workspaces, creating, 115–116

cloud computing

Common Data Service, 57–58

Power BI service, 3

combining, data sources, 168

Power BI Desktop, 118–120

combo charts, 99H

Common Data Service, 2, 15–16, 30,
57–58, 152, 182

business rules, 70–71

conditions, 70

entities, 15, 59–60

Activity, 60

complex, 62

custom, 60–61

fields, 62–64

ownership, 60

relationships, 64–65

representing people, places, and

things, 73–74

restricted, 62

security, 16

solutions, 66

managed, 66

unmanaged, 66

storing app data, 58–59

using with canvas and model apps, 59

complex entities, 62

Compliance Manager, 51–52

component libraries, 155–156

components

model-driven apps, 182

Power BI, 3

Power Platform, 1–2

Compose action, 222

Condition actions, 205

conditional flows, 205–206

conditions, 70

connectivity, Power Platform, 24–25

connectors, 20, 21, 74–75, 163–167,

201

credentials, 196, 202–204

custom

sharing, 82–83

use cases, 79–83

function-based, 201

licensing, 78–79

Power Automate, 21

tabular, 201

content, Power BI, 7, 8

controls, configuring with formulas,

160

Create CSV table action, 222–223

Create HTML table action, 223

creating

apps

canvas, 148–149

portal, 173–176

chatbots, 22–23, 238–239

calling an action, 242–243

creating a topic, 240–242

dashboards, 135

Power BI, 94

DLP (data loss prevention) policies,

50

environments, 46–47

flows, 192, 213–214

live pages, 138

solutions, 66–67

users, 42

workspaces, 114–115

classic, 115–116

custom connectors

sharing, 82–83

use cases, 79–83

custom entities, 60–61

custom models (AI Builder), 89–90

custom visualizations, Power BI,

109–112

customer journey, 171

dashboards, 112. See also apps

building, 135

designing, 136–138

emphasizing importance, 139

screen size, 139–140

Power BI, 4–5

creating, 94

publishing, 141–143
data connectors, 2

data modeling, 120–121

combining queries, 123–126

modifying data types, 121–122

removing rows and columns, 122–123

renaming elements, 123

shared data sets, 133–134

data operation actions

Compose, 222

Create CSV table, 222–223

Create HTML table, 223

Filter array, 223

Join, 223

Parse JSON, 223–224

Select, 224

data sources, combining, 168

in Power BI Desktop, 118–120

data storage. See also Common Data

Service

Common Data Service, 57–58

Power BI Back-End cluster, 37

databases, 73

designers, Power BI, 37

designing, dashboards, 136–138

emphasizing importance, 139

screen size, 139–140

detail screen, 169

developers, 29

citizen, 1, 23, 29, 147, 230

creating solutions, 66–67

digital feedback loop, 26–27

digital transformation, 25–26

DLP (data loss prevention) policies,

49–50

dragging and dropping actions, 222

Dynamics 365, 25, 26, 152

digital feedback loop, 26–27

edit screen, 170

entities, 15, 59–60

Activity, 60

adding to app navigation, 181–183

complex, 62

custom, 60–61

fields, 62–64

ownership, 60

Power Virtual Agents, 235–237

relationships, 64–65

many-to-many, 64

many-to-one, 64

one-to-many, 64

representing people, places, and

things, 73–74

restricted, 62

Entity Extraction model, 85–86

environments, 45–47

equation bar, Power Apps Studio,

170–171

expressions, 208–209

addDays(), 209

categories, 210–211

utcNow(), 209

fields, 62–64

Filter array action, 223

filters, 104, 105–106

Filters pane, Power BI, 106–107

flow templates, 192, 195–200

flows, 16, 17. See also connectors

actions, 198

dragging and dropping, 222

inserting, 221–222

approvals, 211–212

automated, 18, 192

and bots, 238

building, 212–224

business process, 19, 68–70, 194

code view, 20

conditional, 205–206

creating, 192, 213–214

instant, 18, 193, 204

looping, 207–208
modifying, 218–219

running, 224–226

scheduled, 18, 193

sharing, 40–41

UI, 19, 194

workspace canvas, 214–218

folders, CDM (Common Data Model),

73

forms, 185–186

formulas, 158–159

configuring controls with, 160

function-based connectors, 201

funnel charts, 97

gallery screen, 168

gauge charts, 103

Get Data dialog box, Power BI

Desktop, 11

help desk app, 150

home page, Power BI, 4

Home tab, Power BI, 108

I-J

inserting, actions, 221–222

instant flows, 18, 193, 204

Join action, 223

key influencers, 103

Key Phrase Extraction model, 87–87

KPIs (key performance indicators),
102

Language Detection model, 87–88

licenses, 44

connector, 78–79

Power BI, 7

line charts, 98

live pages, creating, 138

looping flows, 207–208

managed solutions, 66

managing

apps, 42

users, 42–44

many-to-many relationships, 64

many-to-one relationships, 64

Microsoft 365, and Power Platform

business solutions, 29–30

Microsoft Azure, and Power Platform

business solutions, 30

Microsoft Teams, Power Platform

business solutions, 27–29

model-driven apps, 13, 150–152

adding entities to app navigation,

181–183

building, 180–181

components, 182

forms, 185–186

publishing and sharing, 187–188

using with Common Data Service, 59

views, 186–187

modifying

actions, 220–221

flows, 218–219

triggers, 220–221

monitoring chatbots

performance, 248–249

usage, 247–248

N-O

navigation pane, Power BI, 109

one-to-many relationships, 64

Parse JSON action, 223–224

PCF (Power Apps Component

Framework), 156–158

people, representing with entities,

73–74

permissions, connector, 202–204

pie charts, 100

places, representing with entities,

73–74

polling triggers, 22, 76

portal apps, 13, 152–153, 173

customizations, 176–178

templates, 173–176

themes, 179–180

user authentication, 179

portals, 153
Power Apps, 13–15, 147. See also
canvas apps; model-driven apps

actions, 76–78

App Designer interface, 151

canvas apps, 148–150, 154

component libraries, 155–156

consumption of AI Builder data,

90–91

controls, 168

data sources, combining, 168

formulas, 158–159

configuring controls with, 160

licenses, 78

managing apps, 42

model-driven apps, 150–152

PCF (Power Apps Component

Framework), 156–158

portal apps, 152–153, 173

Power Automate interoperation,

21–22

reusable components, 154

security, 38–40

Power Apps Studio, equation bar,

170–171

Power Automate, 16, 30. See also

connectors; flows

actions, 76–78

approvals, 211–212

connectors, 21, 201

function-based, 201

permissions, 202–204

tabular, 201

consumption of AI Builder data,

90–91

data operation actions

Compose, 222

Create CSV table, 222–223

Create HTML table, 223

Filter array, 223

Join, 223

Parse JSON, 223–224

Select, 224

expressions, 208–209

addDays(), 209

categories, 210–211

utcNow(), 209

flow templates, 192, 195–200,

218–220

flows, 16, 17

automated, 18, 192

building, 212–224

business process, 19, 194

code view, 20

conditional, 205–206

creating, 192, 213–214

inserting actions, 221–222

instant, 18, 193, 204

looping, 207–208

modifying, 218–219

running, 224–226

scheduled, 18, 193

sharing, 40–41

UI, 19, 194

workspace canvas, 214–218

licenses, 79

My flows screen, 192

portal, 17–18

Power Apps interoperation, 21–22

security, 40

Templates screen, 200

triggers, 75

polling, 76

push, 76

Power BI, 3. See also data modeling

Admin portal, 49

aggregation, 126–128

alerts, 8–9

apps, 6–7, 7

classic workspaces, creating, 115–116

components, 3

content, 7, 8

custom visualizations, 109–112

dashboard, creating, 94

dashboards, 4–5, 112

building, 135

designing, 136–138

publishing, 141–143

data modeling, 120–121

combining queries, 123–126

modifying data types, 121–122

removing rows and columns, 122–123

renaming elements, 123

data types, 128–129

designers, 7

filters, 104, 105–106

Filters pane, 106–107

home page, 4

Home tab, 108

interoperation, 20–21

licenses, 7

navigation pane, 109

and Power BI Desktop, 115–117

Recent tab, 108–109

Report view, 109

reports, 6

publishing, 141–143

security, 32–33, 37–38

Back-End cluster, 35–36, 37

WFE cluster, 33–35

shared data sets, 133–134

template apps, 134–135

visualizations, 94

area charts, 99

bar and column charts, 95–98

cards, 102

combo charts, 99

gauge charts, 103

key influencers, 103

KPIs, 102

line charts, 98

pie charts, 100

scatter plots, 101

slicers, 104

tables, 104

Visuals screen, 110–112

workspaces, 112–113, 113–114

creating, 114–115

Power BI Desktop, 3, 10–11, 31. See

also data modeling

combining multiple data sources,

118–120

data types, 129–131

Get Data dialog box, 11

Power Query Editor, 12

Power BI Premium, 36
Power BI service, 3

Power Platform, 1. See also Power

Apps; Power Automate; Power BI;
Power Virtual Agents

admin centers, 47–48

ALM (application lifecycle

management), 68

Analytics menu, 48

business solutions, 27–29

consumption of Microsoft 365

services, 29–30

consumption of Microsoft Azure

services, 30

consumption of third-party apps and

services, 30

Common Data Service, 15–16

entities, 15

security, 16

components, 1–2

connectivity, 24–25

connectors, 20, 21, 74–75

use cases, 79–83

DLP (data loss prevention) policies,

49–50

environments, 45–47

licenses, 44

Power Apps, 13–15

Power Automate, 16–20

Power BI, 3

Power Virtual Agents, 22–23

privacy and accessibility guidelines,
50–51

triggers, 21

polling, 22

push, 22

users, managing, 42–44

Power Virtual Agents, 22–23, 229

actions, 237–238

chatbots

calling an action, 242–243

creating, 238–239

creating a topic, 240–242

monitoring, 247–248, 248–249

publishing, 232–233

testing, 243–244

entities, 235–237

topics, 233–234

use cases, 229–230

AI (artificial intelligence), 230–231

citizen developers, 230

taking action, 232

prebuilt models (AI Builder)

Business Card Reader, 84–85

Category Classification, 85–86

Entity Extraction, 85–86

Key Phrase Extraction, 87–87

Language Detection, 87–88

Sentiment Analysis, 87–88

Text Recognition, 88–89

publishing

apps, 172–173, 187–188

chatbots, 232–233, 244–246

re-, 244–245

shared reports and dashboards,

141–143

push triggers, 22, 76

Q-R

queries, combining, 123–126

Recent tab, Power BI, 108–109

relationships

many-to-many, 64

many-to-one, 64

one-to-many, 64

renaming, elements, 123

Report view, Power BI, 109

reports

filters, 104, 105–106

Power BI, 6

publishing, 141–143

republishing, 244–245

restricted entities, 62

reusable components, Power Apps,

154

component libraries, 155–156

running a flow, 224–226

S

scatter charts, 101

scheduled flows, 18, 193

schemas, CDM (Common Data

Model), 72

screens

detail, 169

edit, 170

gallery, 168

security, 32

Common Data Service, 16

DLP (data loss prevention) policies,

49–50

Power Apps, 38–40

Power Automate, 40

Power BI, 37, 37–38

Back-End cluster, 35, 37

WFE cluster, 33–35

STP (Service Trust Portal), 50–51

auditing, 52–53

Compliance Manager, 51–52

Select action, 224

Sentiment Analysis model, 87–88

sharing

apps, 150, 172–173

model-driven, 187–188

custom connectors, 82–83

datasets, 133–134
flows, 40–41

slicers, 104

solutions, 66

managed, 66

unmanaged, 66

spreadsheets, 163

stacked charts, 95–96

STP (Service Trust Portal), 50–51

auditing, 52–53

Compliance Manager, 51–52

tables, 104

spreadsheets, 163

tabular connectors, 201

template apps, 134–135

templates

flow, 195–200

portal app, 173–176

Templates screen, Power Automate,

200

testing, chatbots, 243–244

Text Recognition model, 88–89

themes, portal apps, 179–180

third-party apps, and Power Platform

business solutions, 30

tiles

cards, 102

key influencers, 103

topics, 233–234

creating, 240–242

triggers, 21, 75, 198

modifying, 220–221

polling, 22, 76

push, 22, 76

UI flows, 19, 194

unmanaged solutions, 66

use cases

for custom connectors, 79–83

for Power Virtual Agents

AI (artificial intelligence), 230–231

citizen developers, 230

taking action, 232

users, managing, 42–44

utcNow() expression, 209

views, 186–187

visualizations, 94. See also

dashboards

aggregation, 126–128

area charts, 99

bar and column charts, 95–98

cards, 102

combo charts, 99

gauge charts, 103

key influencers, 103

KPIs, 102

line charts, 98

pie charts, 100

scatter plots, 101

slicers, 104

tables, 104

spreadsheets, 163

Visuals screen, Power BI, 110–112

W-X-Y-Z

waterfall charts, 97–98

WFE (Web Front End) cluster, 33–35

workspaces, 112–113, 113–114

classic, creating, 115–116

creating, 114–115

WYSIWYG, 176–177
Code Snippets

Many titles include programming

code or configuration examples. To
optimize the presentation of these
elements, view the eBook in single-
column, landscape mode and adjust
the font size to the smallest setting. In
addition to presenting code and
configurations in the reflowable text
format, we have included images of
the code that mimic the presentation
found in the print book; therefore,
where the reflowable format may
compromise the presentation of the
code listing, you will see a “Click here
to view code image” link. Click the
link to view the print-fidelity code
image. To return to the previous page
viewed, click the Back button on your
device or app.