ArticlesBlog

Tailor your business solutions with PowerApps and the Power Platform

Tailor your business solutions with PowerApps and the Power Platform


>>Hi. This is David Yack, and in this module we’re
going to talk about tailoring the Power Platform through
your specific business requirements. This is the second module in
a three-part video series. In the first module,
we did an overview of the Power Platform and the components
that make up the platform. If you’re just joining us now, you might want to consider
going back and reviewing the overview video before
continuing on to this module, and then after
this module join us for the third and final module
on extending. This is where we dive
deeper into some of the traditional
development waves that you can extend the Power Platform and
unblock complex requirements. Before we get too far into
the content of this module, I want to take a second
to overview what I plan to cover as
part of this module. We’re going to start by
talking about solutions. Solutions is the fundamental concept
to understand with the Power Platform
because it allows you to track all the customizations
that you make. The apps you create,
the flows you create, and be able to transport those
from Dev Test to production. So it’s a fundamental key part of the application lifecycle
management of the platform. The next topic we’ll
cover is data modeling. In this topic we will
look at how you can use the Common Data Service to
store application data. We’ll look at how to take
real-world concepts; things like people, places, other things that you track
in your application and model those with data relationships
in the CDS database. Next, we’ll cover
building applications. This is probably one of the more exciting topics that we’ll cover in this module because it really
brings things to life for the user. This is what they interact
with on a day-to-day basis. We’ll cover the types of
applications you can build. We’ll look at some
of the app features. In fact I’ll go build
a couple apps and show you how you can go about
doing that and also we’ll finish the topic discussing a little bit of what’s on
the roadmap for PowerApps. In the next topic, after
we cover building apps, we’ll move on to automating
things and we’ll dive deeper into using Microsoft Flow to automate
things in your solution. Our final topic we’ll cover
in this module is around application lifecycle
management or ALM. We’ll come back where we
started at the beginning of this module talking
about solutions and we’ll build on that discussion with a little bit more look at how
we move things from Dev Test to production including
how we can use Azure DevOps to automate
some of that process. Let’s go ahead and jump in and
get started with our topics. Before we dive in and
talk about solutions, there’s one other topic I wanted to make sure to cover first to give you some fundamental understanding of how the Power Platform works in
an Azure Active Directory tenant. So when you sign up for
a Power Platform license, any of these cues, that all exist in an Azure Active
Directory tenant. So that is the bounding
box that you can see in my diagram the Contoso has. Within that you have
one or more environments. Every organization has
a default environment. Think about this default
environment as being where you build things for
personal productivity. So if you build a flow, you build a canvas app, and you’re just going
to use it yourself, that’s where you will put it
as in the default environment. If you’re going to build something
that’s more production oriented or something used by
everybody in the company, you might want to consider having a little bit more of
a lifecycle around that. You might have multiple environments. In that example, you might have a development environment that essentially tracks where
you build the application; a test one that you do go
about testing the application, and production one where users
actually run the application from. Now environments are
simply containers that administrators can use to
manage the apps, the flows, the connections, and other
assets that you build along with giving permissions to users
to use those resources. If you have Common Data Service
involved in your solution, each environment can have a single Common Data Service
associated with that environment. So if you had three environments, you would have three Common
Data Service instances if that was how you want to configure things and each would have their own metadata
associated with that. As we talk about solutions, solutions will be created in the context of an
environment and will be used to be a container to reference
a particular set of resources, apps, flows, and so
forth that make up your solution that will move from
one environment to the next. So with that understanding
of environments, let’s talk about how solutions define a container to basically track
the customizations you make. So when you go and
create an app or flow, you have the option of creating that within the context of a solution. One of the things I do when
I start a new project, let’s say I was going to go ahead and track permits that we issue for changes that people want to make to a building and we want to
do inspections on that. That’s the scenario I’ll
use in some of the demos that I’ll do as we go
through this module. Now when I start with that project, what I would probably
do is go and create a new environment that would
be my dev environment. I would then create a solution
that I would track all the apps, flows, CDS customizations
that I make. So if I create an entity
to track permits, I would create that in the context
of the solution and that would be what I use to basically move that from one
environment to the next. So in addition to my
development environment, when I got ready to release this, I would create a test environment
or production environment that would allow users to go
in and test what I built, not contaminate it with any of the other development
things I might have in progress and that once
that test was successful, then that same solution would
be deployed to production. Now to support that,
solutions support the concept of importing
and exporting. So from my development environment, I would export the solution. I would then import that into my test environment to
be able to do that. Now it’s important to know it’s not just the applications that you build that can be installed
through solutions. This is also how Microsoft
installs any of the Dynamics 365 apps that you license
into your environments. These are just solutions
that get installed. In fact, some of
the applications can have multiple solutions that
make up the complete app. As we get a little
further in the module, I’ll explain how
multiple solutions can be installed in one
environment to make up the overall application suite that the user interacts with
on a regular basis. The same is true if you
go to AppSource and install any of the third-party apps built by independent
software vendors, ISVs, these are also
installed using solutions. Solutions allow you to install an
environment and also uninstall. That makes it perfect for trying out an application in an environment. There are two types of solutions,
unmanaged and managed. When you create a new solution
it starts out as unmanaged. Unmanaged solutions are
used during development. They are modifiable directly so you can make changes
to it; add components, remove components and
this is what you export if you want to move it to
another development environment. Solutions can become managed
when you export them from environment that has
the unmanaged solution. When you are ready to
move your application from Dev to Test to production, that is when you would export
the solution and choose the managed option when
you export the solution. That gives you a solution
file that you can import into the test environment or the production environment and it’s
no longer directly changeable. It’s meant for distribution to
the non-development environments. In an environment, you can
install multiple solutions. Every environment
starts with the CDM, Common Data Model System entities already pre-installed
in that environment. You can go ahead and
install other solutions in and they can all
co-exist together and in fact the applications that you build can build on each
other using layering of solutions and what the user sees is the combination of
all those solutions. So let’s take a healthcare example where I have installed
in the environment some Common Data Model
healthcare extensions that were put out as
an accelerator by Microsoft. That would have things
like patient care team, other common health care
entities that might exist. Contoso who’s the
organizations that’s building the solution might have some other
things that they want to add. They may want to add some attributes
to the patient entity or add other custom entities
that are part of their common solutions that multiple applications
might take advantage. Those could be packaged up in a solution and imported
into an environment. Now what the user sees or if you
build apps in this environment is the combination of all of these solutions that
have been pre-installed. So if I was going to build
a device inventory app or a kudos app for my employees do; say thank people for good care
that they gave to patients, those would see all
the entities and attributes combined together that any of
the solutions in that environment. So from Contoso common to
health care extension, as well as what comes out of the box
with the CDM system entities. Most things built on the Power
Platform don’t get built once deployed and they’re
never changed again. Probably one of the most
productive ways that you can take advantage of
the Power Platform is to take advantage of its iterative
ability to build solutions, not have to boil
the ocean all at once. By that, we might get our application to what might be considered
the first minimum viable product that
we could release to users to actually give
some feedback on. They might use that for
a little bit of time, give us some feedback, Tell us about some problems. We might go through make some updates and then
we deploy that again. The solution framework supports this type of incremental
development by making it easy to import new versions and do upgrades as you make
changes going forward. So a common cycle might
look something like this. You make the changes, you
build your applications, your flows and CDS changes, you export as manage, you install that into tests and
ultimately into production. The users give you some feedback. They tell you that
there was a small bug. Rather than shipping
the whole solution again, you create a patch. A patch contains just one attribute, one component within the solution
that you want to fix. You then export
that patch and install that patch into test and
then into production. Now you may have
four or five patches that you create before you build
the next version. Once you are ready to
build the next version, you can roll those patches up into the version two of
the solution that you’re going to make further changes to and then you repeat this cycle
over and over again. That’s how solutions help support an incremental building
of an application. Now let’s go ahead and jump into a quick demo where I’m going
to go ahead and create an environment and create
a solution that we’ll use to track the changes
that we build. Okay, I’ve logged into the Maker portal and I’m
looking at my environments. I currently have the default
environment, one other one. What I’m going to do is
go ahead and create one that I’m going to use
for my development work. So I’m going to go to admin.powerapps.com,
click new environment. I’m going to call this permit Dev and we’re going to go
ahead and create this as a production environment
in the United States. Once the environment is created
it’s going to ask me if I want to have a common data
service database in there. I’m going to go ahead and say yes. I’m going to choose United States
dollar for the currency and I’m going to choose English for the language and let it
go ahead and create. Now that it’s created, am I go back to the Maker portal, I’m going to change
my environment to the permit dev. It may take a minute for
it to show up for you. Now that I’ve created my environment, I can go ahead and create a solution. You’ll notice that I
have a default solution and a Common Data Service
default solution. The default solution gives you a good way to show everything but you really don’t want to use
it for making any changes. If you go to create data
and create an entity, it’ll end up in the Common
Data Service default solution. Right now this is an empty solution. But what I want to do
because I’m going to create a permit
management application. It’s going to have some CDS assets. It’s going to have a canvas app,
a model-driven App. I want to go ahead and create a new solution that I
want to add this into. Now once I’ve clicked Create, I’m a go ahead and give it a name. I’m going to create a Publisher. Now, the Publisher is
used to put a prefix on the entity and track things
altogether that you create. So we’re going to call this Contoso. You may already have one
created in your environment, but the first time you create
it in a new environment, you do have to establish it. So here, I’m setting the prefix as well as the options
set value prefix. So if we create some options sets, we’ll see that number used
there and I’ll go ahead, and say “Save” and “Close”. We’ll go ahead and
pick that publisher, we’ll give a version
number for our solution, we’re going to start out at version one and we’re going to
go ahead and “Create”. Now essentially, we’ve
created a solution that we can track all our customizations
and from within here, you’ll notice that right now it
doesn’t have any components, but I can go create new components, I can create apps, I can create dashboards, entities, flows, reports, and
a whole bunch of other stuff. I can also add existing assets. So if I already had
some things in there or if I wanted to maybe use
the “Contact” entity, so for example, maybe
I’m going to use the Contact to represent who’s
going to request changes, I would just simply add that
in and I could choose it, maybe I wanted to modify
some of the existing fields, I could go in and select the different fields or
relationships, or forms. What I would do is, I would
add in the things that I was going to modify it
to be able to do that. For right now, I’m not going to
go ahead and select anything, but I will go ahead
and add that in so we have something in
our solution that we can see. So as we go through the rest
of this module and we build out the solution as
we do the data modeling, I’ll add the entities in. As we do some of
the other things like building the applications
and building the flows, we’ll do all that in the context of that solutions and
we’ll see this list grow as we work on the rest of our assets throughout
the rest of this module. Let’s move on and talk about the Common Data Service
and implementing a data model for our solution
in the Common Data Service. If you recall, I’m using a permitting
application for buildings. So you want to make a change, you need to get a permit, you need to have inspections, and that’s what I’m
going to model in this. If you listened to the overview, you will remember I talked about
how CDS is a hybrid database where it essentially abstracts the underlying technology
that’s implementing. So there’s relational, there’s
document, there’s file storage, all under the covers of CDS and that is abstracted into the concept
of entities with fields, with relationships
between the entities, and that’s how you model real-world business problems
into the Common Data Service. As part of data modeling, you’ll identify the entities, the fields, the relationships
that you need to create. As you create those relationships, they can be many to one, one to many, as well as many to many. So for example, in my
permit application, I’ve got permit that has inspections. Now, one of the things
that you’ll see me do when we go into the demo is I’ll create that so that
if the permit is deleted, the behavior on
that relationship will cause all the inspections to go away. I’ll use the parental
relationship behavior on there to effectively
remove the need for me as an application to automate the delete of the
inspections if you delete the permit because
the inspections no longer makes sense to stay around
if I delete the permit, because they only make sense
in the context of that permit. So relationships behavior give you that first level of automation
at the data layer for being able to automate how you
want to handle things when actions happen across
the relationship to a parent record. As many businesses these days
work in a global environment, they may encounter
the need for dealing with multiple currencies as well as multiple languages
in their scenarios, and that’s one of the things that Common Data Service has
out-of-the-box support for. So when you create a currency field, it actually adds two fields to the entity that you’re
creating that field on. One that tracks
the transactional currency that you did that in and one that tracks the base currency that
the organization is configured for. This allows you to have records that have their own individual
currency selection, as well as track the exchange rate between when the
transaction was recorded, giving you that out-of-the-box
support for multiple currencies. Same thing with around languages, one of the things that
the platform does is track all the metadata for
labels and descriptions, and all of those can be
exported and you can translate those into the different languages
that you want to support, that allows you to build your
applications that have the labels in the native UI language that the user is comfortable
interacting with. One of the things that’s easily overlooked is some of
the automatic assets that get created when you create a entity in CDS and I’ll contrast
this to for example, if you go create a SQL database
and you create a table in there, you really don’t get as much of a robust application set
of assets that you’d get with the Common
Data Service and that’s the value that the
abstraction layer provides, on top of the underlying
technologies that is abstracted by the concept
of a CDS entity. So in this example, when I create my new entity Building, I get several things in
here, security model, forms, views, automation,
developer API. Let’s start with security models. So effectively, one of
the things you have to often build for an application
is the security model, and CDS implements
a role-based security model. This has the concept
of a security role. A user can have one or more
security roles that combine together to give that user their entitlements to what
they can do with the data. You can also define
the entity ownership. So records in CDS My Building
can either be organization owned where everybody has
access to it or they don’t, or it can get more granular
down to where users can be assigned as owners or teams can be assigned as owners of the record, and security can follow that model
as you’re granting access. You also have the ability to get
down to the field level security. So on Building for example, if I had a field that
was more sensitive data that I didn’t want
other users to have access to, I could turn on field
level security for that and then grant that to only the users
that need to be able to read it, or update or modify that data. When you create the entity, a default set of forms and views are created for use in applications. This makes it easy to
later than compose applications that leverage
those same views and form. You can go in and modify these, and these definitions
can be role tailored so that individual applications
or individual users, have access to just what they need and just the fields
that they need. When you define an application, you’ll actually compose it from
the overall set of forms and views that you’ve defined
associated with that entity. From a process automation standpoint, there’s an event pipeline that’s
built that allows triggering of process automation
after records are created, updated or deleted in the platform. So that means that if I have
a flow that I want to run, it can be automatically triggered, I can get down to what specific
fields that I want to run. Using developer technologies, as we get into the developer
module later on, we’ll talk about how there’s an event pipeline that
developers can hook in before and after that operation
happens in the platform, and that is all built-in
and you don’t have to do anything that
set up that plumbing, you just have to register
your custom logic or your flows to receive those particular events that have been triggered
by the platform. Another common line item
on the budget for a typical project built with low-level developer technologies
is building an API that abstracts you from
the underlying technologies. So for example, if we were
creating this in SQL, we would write something that would
do the calls to SQL but would provide a layer that we’d actually
build our application on. Effectively, that’s what
you get when you use the connectors through flow
or through a Canvas app, you’re talking through the API
that the platform creates. Essentially, the
difference between using this and using the SQL API
directly for example, is the developer API that you get
with the Common Data Service, implements all the
security as well as the business rules that are
implemented at the data layer, as well as any process automation, are all respected by
the developer API when you make calls to
create or read records. That developer API that’s created for the entity is what is
interacted with when you use the Common Data Service Connector through Canvas apps or flows. It leverages that API that’s built for the entity
when you create it, so you don’t have to build any additional API logic
to be able to do that. Now, let’s jump into the portal
and in our solution, let’s add a few entities
so we can see how these all work together and some of the things that we’ve
been talking about. Now, I’m back into the solution
that we created in the prior demo, and I’m going to go ahead
and create our data model or at least part of it as we watch. I’m going to go ahead
and create an entity. Now, the first entity I’m
going to create is going to be the Building entity. You’ll notice I can
pick a primary name, I can decide if I want to have notes, you can do some other settings
like set the ownership and some of the other things that you can explore
on your own time. I’ll go ahead and
create that right now, I’m going to go ahead
and add one other field, this is going to be
simply the Street. We could add other address fields
on it for the location, but I’m going to leave
those for you to imagine that they were on
there in the essence of time. Go ahead and save the entity. I’m going to go ahead
and add another entity, this is going to be my Permit entity. On this one, I’m going to go
ahead and enable attachments. This includes notes and files. This will allow us to attach
some comments to the permit. So as we maybe interact
with the customer, we can go ahead and track
some of those notes. Now, because I’ve turned on notes and it’s not able
to be turned back off, it’s just making sure
that I’m okay with that. I’m going to go ahead
and add a field. We want to charge for
getting the permit. We’ll just call this fee, and I’m going to go ahead and look at the different
data types here. You’ll see there’s a whole bunch
of different data types, several texts with
some formatting, whole numbers, and you can do time zone, duration, language, date, time,
or just date only. We’re going to use
the “Currency” field. We’ll look at some of the other ones as we get a little further along, and we’ll go ahead and add that, and we also are going
to add another field. Notice we can add
multiple fields at once, quickly creating the data model
we have on there. Sometimes, we have to waive the fee. So we’re going to
create a fee waiver, and this is going to
be a two-option field. So a Boolean yes or no, come down to “Two
Option”, then close. We’ll actually do
a business rule on that in a little bit so that if
the fee waiver is there, we won’t require the fee to be on. Go ahead and save the entity, and finally, I’m going to
add one other entity so that we have enough to
build an application with. This one’s going to be
the inspection request. You’ll notice in the background, I didn’t have to actually
hit “Save” there, but my entity had been
provisioned successfully. So it did that in the background. Now, what I want to do is
I want to go ahead and add a relationship on here. So I want to add a relationship from the inspection to the permit
that it’s related to. So I’m going to go ahead and
add a many-to-one relationship, and that is going to
be with the permit. So I’m going to scroll
down and find the permit, and go ahead and add that
in, save the entity, and I’m going to do the same thing on the building because it’s ultimately the building can have
many permits issued against it. So I’m going to create a one-to-many
from the building and we’ll associate that with
the permit as well. So essentially, we’re building up the relationships all
around our entity on here. Now, one quick change I want
to make just to show you how easy it is to go back and
change things on the model, I want to make so that that
relationship between inspection and the permit is a parental relationship so that if we delete the permit, we want to essentially remove the inspections
that are related to it. We left that option as the default. So if I go double-click
on this again, go into “Advanced options”, we’ll see the type of
behavior set to referential. I can change that to parental, and what’s going to
happen now if I delete a permit once I’ve made this change, it will delete all the inspection. So that’s how you can automate
some of the management of the records across
the relationships. Now that we have
our basic entities created, I want to go ahead and
add a business rule. The rule I want to do is I want
to do this on the permit entity, and basically if the fee
waiver is turned on, I don’t want the fee to be required. So I’m going to come over
here to “Business rules”, I’m going to go add a business rule, I’m going to go into my “Condition”, and I’m going to say, “Check if fee waived.” We’re going to check if the fee waiver field is equal to yes and then click
“Apply”, and if it is, then we’re going to “Set business
required”, set not required, and we’re going to set this
as “Not business required”, and we’re going to set
that on the “Fee” field, and then if it is required, we’re going to drag this over here, and we’re going to say on here, then we’re going to
say “Set required”, and this is also going to
be on the “Fee” field. We’re going to make this business
required this time, and we’re going to go ahead
and give our rule a name, “Set required if not waived.” We’ll go ahead and save
this rule and activate it. Now, at this point, this rule becomes active. So when somebody uses the fields, it becomes a required field
if the fee waiver is not set, and we’ll see that come
to life when we go build a application that
uses some of the data. Now, you’ll notice
if I come back over to the portal and
look at the solution, we’ve got a few more things in here. We’ve got a business rule
that’s now showing up set required if not waived. One last thing I want to
be able to do is I want to jump over to the Form Designer. Now, in the Form Designer, you can add all sorts
of things on here. So you can add the different layouts, you can add the
sections, the columns. What I’m going to do is I’m
going to keep this real simple. I’m just going to go
ahead and drag on the “Building” so that we can add the building that
this permit is related to. We’re going to add the fee, and then I’m also going to
add the fee waiver on there. You notice how quickly I can go
ahead and put together this form, go ahead and publish this, and the final thing I want
to do is I want to come back and I want to use one
of the other designers. I’m going to go into “Views”, and if I open up my active permits, you’ll notice that it’s
built a default view for us. When you look at
a list of the permits, this is what you’re going to see,
and so what I want to do is, I want to add on to this that
we have the building in there, and that we have the fee that
they paid for that permit. We’ll make that a little bit bigger, and we’ll go ahead and save, and that’s how we
customize the views. You can build multiple views.
There’s criteria. So down here, I can come
in and edit the filters, and this allows me to build
all types of criteria. So I can say where the status, where the building, created
by is in the last six months, all kinds of criteria
so that your view filters the data the way
the users want to see it. So that’s a quick look at building a data model and building some
of the other assets around it. We also built the forms
and the views, and later on we’ll actually build an application that uses
some of these assets. In the introduction module, we introduced you to
PowerApps is the ways that you build applications
on the power platform. We talked about how if you’re doing
any Office 365 customizations, you use PowerApps, if you’re
modifying a Dynamics 365 application, you’re modifying a PowerApp, and if you’re building
a custom application for either your own internal
use or as an ISV, PowerApps is the way that you build the applications on the platform. Designer or Canvas Studio, you compose the application
and you leverage the connectors to work
with data and services. When you start creating a PowerApp, you’re going to make a decision
of how you want to start, whether you want to start with a
Canvas app or a model-driven app. How you make that decision depends on how you’re going
to want to control the user experience as well as the data that you’re working
with in the application. If you want complete control over the user experience,
in other words, you want to start with
a blank slate and define what the user
experience looks like, then the Canvas apps gives you that complete control over
that user experience. If you’re going to start with data
from the Common Data Service, then a model-driven app
gives you a quick way to get an application up
and running that has lists of data, forms of data. Essentially, data-editing
type applications can be really quickly built using
the model-driven style. Now, if your data doesn’t
come from CDS or it comes from CDS and
some other data sources, the Canvas apps through the
connectors allow you to [inaudible] that data together on
the design surface. It’s important to remember that you’re only choosing where to start. You can always combine, for example, a Canvas app inside a model-driven
app as one of the components, and we’ll talk more about that as
we continue through the modules. If I were to generalize
the PowerApps app architecture, it would look something like this, where you have an app that’s
composed of one or more pages, screens that you combine together, and on those pages and screens, you group things together
either through tabs, sections, or groups, and in those groups,
you have components. The components could be as simple as a very basic control
like a text input box, or it could be a more complex
control that is more of something built by
a custom developer or a Canvas reusable component
that could be built using similar constructs that you
will build the Canvas apps with, and we’ll look at that as we jump in and go through a demo
of building of apps. Now, I mentioned that starting from a model-driven application if
you’re working with CDS data can be very beneficial because
it’s really quick to get an application up and running
that has a list of data, forms for editing the data, but it also comes with a number
of other features that are just, they’re out of the box without
you having to build things. For example, things
like personal views allowing users to define
views that they want to have, maybe records created
in the last six months, records that have been inactive, and it also provides controls, things like timeline
activity views that allow it to see all the
interactions a record has. So for example, if you’re tracking appointments, e-mails, phone calls, all sorts of interactions
against a record, the timeline view gives
you a very easy way to see what’s been
happening on that record. From a user productivity
point of view, some tools like Excel Integration or Document Templates are built-in, allowing you to quickly create
Word documents for example, from some of the data that’s in the list as well as other
productivity things for the user, like recently viewed,
recently pinned. You don’t have to go build
those into your application. Earlier, I talked about
the ability to do localization of the metadata
for entities in the field, just changing the labels
and having them display in the local language. That all happens automatically. So if you have the language
configured on your environment, the user can choose
that as their language, so if I wanted French or German, and then the user experience
would be adapted to use the labels that you’ve done the
localization on for that language. If you didn’t provide
one for the language, it would fall back to the default
one for that solution. Now, let’s actually jump over
and build a couple of apps. We’re going to build, first, an application that will be used by the back office team that
will manage the permits. This will be a model-driven
application that will allow the user to
basically input the permit, schedule the inspection,
and then we’ll build a Canvas app that will be
used by the inspectors. These are the people that
go out into the field. They’ll be using their mobile device, so we’ll give them
a very tailored application that can just do the inspections. Let’s go ahead and take a look at building both of these applications. Now, I’m back in the solution. We’ve got our data model
that we created, and I’m now going to go ahead
and add an application. I’m going to create
a model-driven application for the back office to be able
to manage the permit. Call this Permit Manager, and we’re going to go
ahead and pretty much take the default options here. You could provide
your own app image and some other settings there if
you want, a welcome page, which is a splash screen, but I’m going to go
ahead and click “Done”. I come to the App Designer, and I basically see that I don’t currently have
any entities configured, any dashboards or processes, and my Site Map is asking
for me to configure it. The Site Map controls the
navigation of the application, and this is where we
start composing things. So what I’m going to
do is go into that, and I’m going to go ahead, and in here I’m going to change
the area to be permit management. The group called as Issue Permits, and then in the area, I want to go ahead and start
putting some of my entities in. So I’m going to go to “Entity”. I’m going to go ahead
and put this to Permit, and that will cause the Permit
to be in the navigation. I’m also, just for
my own convenience, going to go ahead and
add in another sub-area. I could do this from there
or I could come drag it from components like we did
with the business rules. I’m going to go ahead and on here, I’m going to put “Entity” in again. Now, you’ll notice that you
can put some other things: the Dashboards, Web Resources. You can even point to a URL, so maybe you have
an external site that you want to bring into
the app navigation. You can do that as well. I’m going to bring this in and
this is going to be the Buildings. We’ll go ahead, and “Save”
this, and we’ll “Publish”. Now, at this point, we’ve successfully configured
the site map for our application, and we can go ahead, and save, and close this, and get
back to the designer. Now, notice what’s happened. Because we’ve added
those entities to our navigation, we’ve now got those
referenced by the app. They show up in the list. We can actually work
things from here. So we can actually
click on these items. This lets you control
what forms would be available. You can actually have
multiple forms for an entity, multiple views, and from here, you can actually
de-select and configure specifically for this
application what forms, views, charts, dashboards are available to users
of that application. We’re going to take it, just
leave it as all for right now, and I’m going to go ahead and “Save”, and I’m going to go
ahead and “Publish”. I’m going go ahead and
run our application. That’s how quickly it is to build a very basic model-driven
application. So essentially, at this point, we’ve got ability to
do some data entry. So I’m going to go ahead
and create a new building. We’ll call this
Microsoft headquarters, one redmond way, “Save and Close”. Then, I’m going to go to “Permits” and I’m going to go
create a new Permit. This is going to be a Room Addition and we’re
going to pick the Building. Now, notice because this is a relationship between
the Permit and the Building, I now have what’s referred
to as a lookup field. It’ll give you a quick shortcut that it records you’ve used recently. You can create new ones from here. You can search. This would actually launched a search process where
you can change the views. You can search for the records. I’m going to go ahead and
pick Microsoft Headquarters. Now, notice that my fee is required, but watch what happened, and I can tell that because there’s a little red asterisk next to it. Now, if I change this to
“Yes” that the fee is waived, notice that it’s no longer there. That’s the business rule that we created that it’s
implementing that rule on the fee field allowing me to
make it required or not required. I could also use that to set values and all other types
of things on there. So we’re going to go ahead
and leave that not waived, and go ahead and set
it to fee at $500, and go ahead and save the record. Now, you notice over
here on the right, that’s the Timeline control. We had that because
we had notes enabled. So Establish Permit for Bill Gates, and I could, will pay later, and I could go ahead and add notes. I could attach things to it. I could also add
other activities to it. So things like if I wanted to
have tasks and phone calls track, those could all show
up in the timeline, so you could see all of
the interactions that happen there. You can also go to “Related” and
this is where you’re going to see other related records
to this entity. So I have “Inspections”. So if we had some inspections, we could see what those inspections, and that’s how quickly you can build a basic model-driven application. Now, let’s go ahead,
and switch gears, and look at building
our Canvas application for our inspectors
that are going to go out into the field and
do the inspection of that room addition once
it’s ready for inspection. Now, I’m back in our solution, and notice that we’ve got our
Permit Manager showing up in here, our model-driven app, and
also a client extension, that’s our sitemap
for the navigation. Now, what I’m going to do is go ahead and create our Inspector application. So I’m going go ahead
and create an app. But this time, I’m going
to choose “Canvas”. I’m going to use the
“Phone Form Factor” because they’re going to use
it on their mobile app device. Once the studio starts, you find ourselves in the application with a blank slate that we
can do whatever we want. Now, notice we don’t
have any application, navigation, or anything,
that’s all up to us to build. So the first thing I’m going
to do is I’m going to go ahead and connect to one
of our data sources. So I’m going to go to
view “Data Sources”, and I’m going to go ahead
and add a Data Source. This is where you
can get all kinds of different data from SharePoint
to Adobe Creative Cloud, Adobe Sign, any data or service
that is available to connect, you can do from here. So I’m going to use the
Common Data Service. So I’m going to say,
Common Data Service, and I’m going to go
ahead and choose that, and I’m going to “Create”. It’s going to have me choose
the entity I want to work with. Now, I want to work with
inspections right now. So I’m going to go ahead
and choose “Inspections”, and now that’s associated
with my application. Now, what I want to do is I want
to go ahead and give a quick list of inspections that this inspector
has available to them. So I’m going to come in and I’m going to do an insert of a gallery. I’m going to make
this a “Vertical” gallery. We’ll leave this blank for right
now because I’m going to go ahead and customize the format of it. Now, I’m going to go
ahead and add into this gallery a label that will
be the name of the inspection. So we haven’t connected
this to any item yet. Right now, it’s just set to
this customer default galleries. So notice what’s
happening up here is I clicked on this gallery and
control that I’ve added. It has different properties
that you can work with. This is the items’ property that says what data is connected to it. I’m going to change
that to be Inspections. Now, notice what happens
when I start typing, I get the IntelliSense hints
that makes it easy for me to find the data that
I want to connect to. You’ll notice that I’ve
now got this populated with some data it’s pulled
in the created on day, but what I really want to
have is I want to have that be the name of the inspection, which will tell me a little bit about what type of inspection
I’m doing on there. Now, you’ll notice that I get
real-time as I make these changes. I’m able to see this happen on here, and I’m able to real-time
make adjustments, and see the results of that. In fact, I’m going
to go ahead and add the street address of the building. So I’m going to come in here and
I’m going to add another label. Then, this second field, what I want to do is I know
this is related to the permit. So I’m going to be able to
just simply say.permit, and that uses the relationship, and that gives me access to
all the fields on the permit. So I wanted to just show the name of the permit that
I’m putting on there. That way, we can see that
it’s a room addition and it’s add a restroom. Now, if I want to size
this up a little bit more, you’ll notice I can pull this up. If I wanted to each item
to be a little smaller, I could go ahead and do that. Now, there’s all kinds of
things that you can do on here. So we could have forms. So like if I needed
to add an inspection, I might have them use
a “Edit” Form to go ahead, and fill out the results
of the inspection, and do update some fields on it. I could do a “Display” form, which is more of a read-only. You’ve got “Media” controls. So let’s actually go ahead and
just add some navigation on here. Let’s first of all, we’ve got our first screen. You’ll notice from here, I
can do all kinds of things, like I can rename this
and call this MainScreen, and I can go ahead and if I want, I can add a new screen. This gives you some ideas of layouts. Do you want it scrollable? Do you want it to be a list? I’m just going to go
ahead and choose blank, and then I’m going to
call this the Inspection. On here, what I’m going to do is maybe they want to actually go
use one of the media controls. So I can upload an image, I could use some of the device
things like scan bar codes, I can also use the camera. Now, what we’re going to do is go ahead on here and just
for a simplicity, we’re going to use the display form, will display some information
about the selected permit. So what I’m going to do is
I’m going to go ahead and set the data source on this display form
to the inspections, and I’m going to go ahead
and set the item none. Notice how I’m working with
these properties to buying them to the other control some will
say this is gallery1.selected. That’s the item that we have
selected in the other control, and I’m going to go ahead
and edit the fields. Now, what I’m doing here is I’m essentially taking from
the fields that are available. So I’m going to go
ahead and bring on the created on-field, the name field, we’ll just keep it as
a couple of those may be modified on just so we can
see if it’s been changed, and we’ll go ahead and drop those on. This gives us a display only view, you can actually set some of
the properties depending on the field type you can choose
how it’s going to display. Now, what I want do is go ahead
and set up some navigation. So we’re going to just
so we can do this, I’m going to drag this
down a little bit, I’m going to go add an icon, and we’re going to add a back button. We’re not trying for
the prettiest thing on here. Notice the OnSelect that’s
a behavior property. This lets me do a formula. Formula is how you
cause things to happen. So I wanted to do and navigate
back to that prior page, I could use the navigate and
specify the actual page, but what I’m going
to do is simply use the back function to tell it to go back to whatever navigated to it. Now, to get to this page, I’m going to go back
to the main screen, edit the control that we
have on here this item, and I’m going to go ahead
and add an item icon on here so we can use
it to drill down. Go ahead and click that, we’ll drag that over, and on this one on the select, we’re going to navigate to
our inspections screen, and now we can actually
run our applications. So far we’ve been just previewing it, and I could hold down the ALT key
and it would let me do the navigation from without
launching the application, but what I can also do
is quickly jump into the player by a pit and the play
up here and run the application, and you can see the list
of inspections. I can go ahead and go back, and forth between it. So we can see how you can very easily craft and compose
your own application, but a very different from what we saw with the model-driven application where we just basically said what entities want to navigate
and everything was build, everything we want to have in the Canvas app gives
us a lot of control. It’s a blank slate, but we have to build that out. So things like we might want to have a little bit
of a header controls. So what I might do is I
might come down here, I might want to have
a header control on here. So I might bring this up here, make this a little bit prettier, and you can do all things
to make this personalized, so that we can say this
is the inspector app, this is our name, and we could even go and do
some formatting of that. So we could choose the color or
maybe we want it to be white, and all of this is done visually
through the application, and you can see how
you can incrementally build this as you
work through things. Now, one other thing
I wanted to call out you’ll notice if I come in here on this and I actually change
this permit named to Dave, you’ll notice I get
the little error up here, but also on the right-hand side
this app checker, the little stethoscope up here, it’s highlighting that, I’ve got
a problem in one of my formulas, and it tells me where that
is and if I click on it, it will take me to their. That’s a quick way to know how to resolve errors and if
you have any problems. So app checker is there to give you that real-time until
a sense of what’s going on. That’s a quick look at building both a model-driven app
and a canvas app. Now, that you’ve seen
a couple of apps built using each of the styles
model-driven in Canvas, I wanted to come back and give you a little insight into the road
map of where things are headed. Now, obviously the end goal is
to not have necessarily some of the two different ways that
you build applications as much as the applications are productive
and that you build them today, you’re going to see over time over
the next 12 to 18 months them come together into a single
app designer where you’ll be able to mix and match the application types even more
seamlessly than you can do today using some of the embedded capabilities of
putting Canvas insight model. Now, the first part of
that journey is introducing responsive custom pages into
the Canvas applications, and so that will be coming
as a first enhancement allow you to have a page that not only will be
responsive as you size it, but it will have the
ability to have groupings. So where you can put the components and lay it out very
similar to what you might think of when we laid
out the model-driven app form, and we have the concept
of tabs in the sections. By introducing that Canvas page that will be available for
Canvas apps initially to use. So you could just add that as
another asset to your application. Not long after that, you’ll be able to add that Canvas
page also to a model-driven app giving you an additional
way to leverage Canvas inside a model-driven app. The final step in the convergence of the application types
is being able to use a single studio and
a single user experience for running the applications. When you’re in the studio, you choose the type of
page, form, or view, or dashboard that you want to add
to the navigation of the app and the components can be shared between the different types of
pages whether it’s forms, views, without having
regard to what type of application is whether it’s
model-driven or canvas. The most important thing to
understand about the convergence of the app types is as you
make applications today, they will not be impacted
by the conversion, and the only thing that
will happen as you get down the road and you’re able
to have the apps that are combined is you’ll be able to do
more with the application all within a single studio without leaving to go to different designers. Let’s move on from applications
to talk about Microsoft Flow. In the overview module, we talked about what
a flow looks like. We talked about how
a flow has a trigger that causes the flow
to start execution, and then it has one or
more actions that provide the actual logic that you want to
have happen when the flow runs. Now, as you start to build your flow, the first thing you’re
going to do is configure the trigger that you’re going
to use to start the flow. There are different types of triggers that you can use to trigger the flow, and they have different
characteristics. The first are instant flows. Instant flows are ones that trigger when the user
takes some action. An example of those is the Flow
button in the mobile applications. So when the user clicks it, the flow runs instantly
right after that. If from Excel, you can have it
on a selected row in the Excel passing in the context of that
or from Common Data Service. So from a model-driven
application maybe I’m on the permit row and I want to run a particular flow against that permit that was issued
or against the building, I can have the trigger B when a record is selected and
that will cause it to show in the list in the user experience and
allow the user to click it. Now, with each of the instant flows you can
pass some parameters to them. So on the permit maybe I want
to apply a fee because it was late or the inspection failed and they have
to do a re-inspection, so I could run a flow and as
part of running that flow, I can be prompted for
the $50 extra charge for the additional trip charge for
doing the secondary inspection. The next type of flow
is a scheduled flow. Scheduled flows allow you to run
them on a reoccurring basis. So you might say that I wanted
to start today at 10:00 AM, and I wanted to repeat every minute, every hour, at once a week, these are perfect for
things that you need to run on a reoccurring basis. The next type is
the Power Apps trigger. This allows you to from a canvas
application have a button or other action control on there
that triggers the flow to run. Take a scenario where we have an inspector that’s out in the
field they’re getting ready to go to their next location for inspection and they want
to advise the people that they’re on their way if
the customer had to ask for 15 minute notification
before they arrive. So literally by just simply clicking on a button that could
cause it to invoke a flow, that flow could then do
the check on the record to see if the customer
requested a notification, if it did requests notification
and has a cell phone number, it could use one of
the SMS connectors to send an SMS saying that the inspector
is 15 minutes out, and all that can happen
in the background just by the inspector pushing the button
in the Power Apps canvas app. The final category of
trigger types is Automated Flows. Examples of these are things like new file is added to
a Dropbox folder, new item is added to
a SharePoint list, or the Common Data Service where a new record is created,
updated or deleted, and you can even get
down on for example, on the Common Data Service ones, you can provide scoping as
well as filtering attributes. So maybe I only want to know when the contacts first name and
Last name have changed, any other change to that contact, I don’t want to run the flow. To build the flows, you’ll use
the flow designer which is a visual designer you’ll assembly search for the trigger
that you want to use, you’ll configure any options, you’ll then add the additional steps, and then we’ve got an example of
one here that’s a little bit more robust than the one I showed you
at the beginning of this section. On this one we’re triggering
based on a new e-mail that’s arrived in the e-mail
box of the user. They’re using the Get
my Profile action to find out who their information is. So that would return David Yak
and my e-mail address, but what I’m really interested
in is my manager here. So it’s doing a get on my manager that allows us to get
the e-mail from the manager and allows us to do
a condition check to say is the new e-mail that
arrive from My manager, and if it is then posted to a Slack channel with that particular
information to highlight it. So this is just a simple
self productivity example. We’ll go and build another flow
when we get into the demo on this, but from building this you could also use some of
the tools like Flow Checker. Flow Checker allows you to
highlight if there’s any errors, it’ll highlight what errors exist, similar to App checker was for
the Power Apps Canvas apps. It also has built-in testing
to allow you to test the flow, and I’ll talk a little bit
more about that in a second. Both the built-in checker and the testing capabilities
are designed to make it easier to build flows and resolve problems that
you might run into. This highlights what
Flow Checker looks like. So you can see that I’ve got
three errors that I need to resolve. One of them needs an entity name specified and the other needs
the file name and the file content. So I can click on those, it’ll take me right to where
I need to in the flow, as your flows get a little bit
more complex that helps you find the things that you
need to fix a lot quicker. The testing capability helps a lot when you incrementally build a flow. It allows you along
the way as you’re building it out to test it periodically
to see the results, and then go make additional
changes and do it again. Now, what you have the ability to do with the testing is when you click on “Test the Flow” the first time you have to perform
the trigger action. So if it was when
a record is selected, you go to the application, you’d run it against a record, and then it would run
your flow interactively. You’d see it go through
the steps and you’ll be able to see the outcomes from
each of the steps. You’d be able to click
“Edit” make any changes. Now, after that first time, you would then be
able to use data from a previous run because
you’ve already run it once, and it would allow you to pick from the last few recently runs
of that flow, you pick the record,
you save and test, and it’s going to rerun it again, and you can then repeat that process
going through the test, edit, test, edit until you get the results that
you’re looking for. Let’s go ahead and jump into
the flow designer and build a flow. Okay. We’re back in our solution. What I want to do is go
ahead and create a flow that runs when a new inspection is created and sends an e-mail
to the inspector to let them know they’ve been
assigned an inspection. So what I’m going to do is come
in here and do a new flow, that will launch the Flow Designer. Now the first thing
I’m going to do is I’m going to be prompted
to select a trigger. So I’m going to use the “Search” and I’m going to look
for the Common Data Service. I’m going to choose
the current environment one because building in a solution that selects the environment that
I’m currently in. I’m going to select
the “When a record is created, updated, or deleted.” We’re going to configure that to
run when a record is created. You’ll notice though,
that you can choose to have combinations of
these of it makes sense, but we’re going to go
ahead and stick with that. We want to run this when
the inspections are created. We want to run on any records that are created regardless
of who the owner is, so we’re going to show that on there. Some of the controls
have additional options. You always want to take
a look to see what you have. Now that we’ve triggered, that tells us we have a new record. What I want to do is I want to get the user information
associated with that. So I’m going to go ahead
and do a new step. This time, I’m going to do a Common Data Service
again because I’m going to retrieve the user record that is
the owner of that inspection. You’ll notice that
when I click on this, there are several different
actions I can now take. I can create a record,
I can delete a record, get a record list, update. You can also use
the AI Builder to run the prediction’s off one
of your AI builder models. But what we’re going to do is, we’re going to do a Get record. We’re going to have it
look up the user record. So we’re going to pick users. Now I need to pick
an item identifier. This is the ID of the records.
So I’m going to click on this. You’ll notice what happens
when I click in the field, that it shows this dynamic
content panel over here. This allows me to see data
from the prior steps. What I want to do is, I basically want to go
down and I want to take Owner and I want to take
the value of that owner ID. I’m going to use that
to look up the record. I’m going to go ahead and
change the name of this. You’ll notice on each of these cards, if you click on the dot-dot-dot, you could get settings, you can rename them. I’m going to call this GetUser, and that’s important because
it allows you to easily reference things and know what it is when you’re referencing later on. To keep this simple, I’m going to go ahead
and send an e-mail, where we’re going to use
the Office 365 connectors. So notice now, we’re using
another connector as part of this. So we’re going to go
ahead and send an e-mail. We’re going to specify
who it’s going to. We’re going to do that by using
the e-mail from the other user. We’re going to use
the primary e-mail. Notice that this “GetUser” shows up, so it’ll makes it easy
to find that on there. We’re going to say that
you assign new inspection. Just for simplicity six and
the body of the e-mail, we’re going to go
down and bind that to some data from the first
when a record is created. We’re going to bind that
to the name field of the inspection that
they were assigned. Now at this point, we could actually drag things
around and move things around. We want to give this an actual name, so we’ll call this Notify Inspector. We’ll go ahead and save our flow. Now that we’ve created our flow, what we want to do is
run a quick test on it. Notice that just like app checker, there’s also Flow Checker. I don’t have any errors. If I had some, that would show
up here and I can resolve them. Just like we did in the Canvas app, with the app checker, we can resolve them there. I’m going to go ahead
and click “Test”. Now, you get two options. Remember, we talked about this. I’m going to do the
perform the action, we’ll hit the “Test”. Now at this point, my flow is sitting here, waiting for me to create a records. So I’m going to come over to
my model-driven application, and I’m going to go ahead and
add an inspection record. See if done yet, when save and close. I’ll come back over to my flow. As it picks up that record, we’ll see that start processing. Once a flow is processed, you can look at the results of it. So you can click on
each of the items. You can see what some of the values are and what
the data that was returned. You can see that it’s
sent the e-mail. Okay. That’s an example
of being able to do that. So if we came back to our solution
now and click down on this, you’ll notice that we now
have a complete solution. So we have our entities, we have our model-driven app, we have our canvas app, we have our business rule
that we created. We also have our notify
inspector application flows, showing up on there. All these are combined
in one solution. Now, if we wanted to
move this to test, we would simply come over here, do an export, and we would
basically export it as managed. That would give us a file
that we would then import into that other environment. If you came here from more
of an Azure background, you might be looking at
Microsoft Flow and saying, “Wow, that looks really a lot
like Azure Logic Apps.” That’s no coincidence. Microsoft Flow is built on
top of the Logic Apps Engine, and the majority of the connectors
and capabilities are the same. There is a difference however, in how you pay for execution
of a Logic App versus a Flow. Logic App runs on a trigger
action consumption model. In other words, in the context
of an Azure subscription. For each trigger and
each action that runs, your paying incrementally
for each of those. Whereas, Microsoft Flow is
based on the total run. So if the flow runs five times, that is decremented from
your allowance that you get for a power platform license. There are a couple other areas
that you should be aware of differences between
Flow and Logic apps. One of them is around
the deeper integration that Flow has with the
Common Data Service, including ability to package a Flow with solutions to
make deployment easier. Whereas the Logic Apps is
deployed using the arm templates. Azure Logic Apps have access to
enterprise integration features like B2B EDI that is also not
available in Microsoft Flow. Nothing says that you
can’t use both Flow and Logic Apps as it’s appropriate
for your particular solution. But Microsoft Flow has a lot of
characteristics that make it very desirable to use if you’re building
other power platform assets. As I went through this module, you saw how I use solutions to track the customizations
that I built. Each time we build
an additional asset, we did that from the context of the solution that
we were working with. That was done in
our development environment. We could define test and
production environments that we could deploy
that solution to. The next step in
formalizing and making a little bit more robust application lifecycle management process
out of it would be to leverage something like Azure DevOps
to be able to do some of the actual tracking of the solution
changes that you make. So we could use the Git
Repository that was part of Azure DevOps to store the changes that would allow
tracking the individual changes, and allow teams to have
a little bit more velocity of the changes that they make without
conflicting with each other. We could then use the CI/CD, the continuous
integration/continuous deployment processes that we could
build the pipelines, to basically automate the process of exporting the solution
from source control, building the managed solution, and then using the release pipelines
and approvals if we want to deploy that to our test and
production environments once it got approval from testing. By leveraging Azure DevOps, we would have
a more repeatable process for managing our
application that we built. That brings us to
the end of Module 2, where we looked at tailoring
the power platform for our specific
project requirements. I wanted to leave you with
some additional learning resources, as well as some customer stories
to get you excited about things that you might want to
do in your own organization. I hope all of you join
us in the third module, where we look at extending, diving deeper into some of
the techniques developers can use to unblock
the more complex requirements.

Comment here