ArticlesBlog

Overview of building solutions on PowerApps and the Power Platform

Overview of building solutions on PowerApps and the Power Platform


>>Hi. This is David Yack, and in this video series, we’re going to walk through
a technical overview of building solutions with
the Power Platform. To make it easier to consume, we’d broken the video series
down into three modules; overview, tailoring and extending. You can consume these as it
makes sense based on your role, although I recommend
consuming them in that order. In the first module overview, we’re going to take
a high-level look at the business problems
that are trying to be solved by the Power Platform. Will look at the individual
components that make up the Power Platform so you
understand how they can be used individually or together to gain the most benefit
for your organization. In the second module, tailoring, we dive a little bit deeper into the customizations and configuration
capabilities of the platform. So this is where we talk about
actually building applications, automating things with Microsoft Flow and really going deeper into some of the technical aspects of how you build applications on
the Power Platform. In this module, we’ll see some of the low code aspects of
the platform come to life and allowing anybody across the organization
to build solutions. In the third module extending, we’re going to take a look at one of the unique characteristics
of the Power Platform. It’s ability to unblock low code
solutions by going a step further into high code where we use
traditional developer tools C-Sharp, Visual Studio, to
extend the platform. In fact, you can also extend
that into Azure leveraging all their traditional Cloud
techniques that you would use building directly on
the Azure Cloud platform, getting the best of
the overall full Microsoft Stack. One of the key goals of the
Power Platform is to enable digital transformation
across the organization and that means different things
to different companies. But at the heart of it
obviously that involves some modernization of
the workplace, leveraging AI. But really to get
the most advantage of it, you have to have some focus of how you want to go about doing this, and Microsoft really
focuses on four key areas. Empowering Employees,
Engaging Customers, Optimizing Operations and
Transforming Products, and you’ll see a lot of what the
Power Platform implements as new features as well as
the applications that Microsoft comes out with that builds on top of the Power Platform really
goes after enabling organizations to exceed in digital transformation
across these four pillars. Now, it’s easy to think of
digital transformation as just being a buzzword that’s thrown
out by people in the industry, but to give a tangible way
of thinking about it. If you look at how we used
to build applications, they were very reactive. We’d have somebody sitting there
waiting for a call to come in. They would then create
a record in the system that would possibly have
somebody go out and they do some last-minute
effort to try to resolve the problem that
the customer was having. Now, what we have with the
Power Platform as well as some of the Azure Cloud Services things like Azure IoT that enable us to get
more telemetry from the customer. We can do things like
anomaly detection, which allows scheduling
proactive maintenance, and therefore we’ve actually
turned on in how we go about solving customers problems by trying to avoid them
in the first part. Now, what’s also shifted
is the ease of ability to build solutions where we used
to be in the reactive mode, but it used to take years
to build these solutions, and in fact many of you have these system sitting around
that hadn’t been touched in 10 years that you’re just nursing along hoping that you don’t
have to reinvest in it. With the Power Platform, you have the ability to
build smaller applications. These applications can be built by people closer to the line of business or by more professional staff that is chartered with
building those solutions. But it really allows them
to get to market or get to use in the organization
in a quicker pace, that allows companies to react quicker to what they’re
seeing as feedback from their customers or reaction to the marketplace of their products or services that they’re offering. When it comes to implementing digital transformation
with the Power Platform, there’s really three key
strategies that you can apply and you don’t have to
choose just one of them. You can actually apply all three
depending on your circumstances. The first is leveraging Dynamics
365 suite of applications. This includes sales service, field service as well as operations applications that are prebuilt by
Microsoft on the Power Platform. If the problem you’re trying
to solve in your organization doesn’t fit one of the
Dynamics 365 applications, you should look to AppSource. AppSource has listings
for all the ISVs, independent software vendors
that build solutions on the Power Platform that
you could start with. So these might be ones
for specific verticals or might solve certain challenges that you can implement for
your organization. Now, if your problem
doesn’t fit either of those other two approaches, you can take the third
approach which is built custom applications starting from either one of the first two approaches or by
starting with a blank slate, an empty database and
building up from there, and we’ll be talking about how
you can leverage all three of these approaches as we go
through the rest of the module. Power Platform is made up
of three key components. Power BI, PowerApps
and Microsoft Flow. Each of these provide
a capability that you can use individually
or used together. Power BI I is focused on analytics, basically visualizing
data in a meaningful way, that data come from
one or more sources and be presented for decision
by business users. PowerApps is all about
the user interaction. So this is how you build applications that users interact
with on the platform. This is what is used to build Dynamics 365 applications as well as many of the apps that
you’ll find in AppSource. Microsoft Flow is all about automation of workflow
in your organization. So this is packaging up in
predictable repeatable processes, automation that can work to
save users a lot of time. It can also be used
for integration across services using the data connectors
that we’ll be talking about. Opening one of the things
that’s unique about the Power Platform is
your ability to leverage traditional development
techniques as well as Azure to unblock things that
would be typically blocked at a low code platform, and this allows you to take parts of the application
where it makes sense. leverage things like
Azure Cosmos database or some of the cognitive services or
other approaches that come with Azure Cloud services or simply
require a developer to build more high code solutions along with the low code solutions
that you build using Power BI, PowerApps and Flow. Now, all of this can be
orchestrated together to deal with your ongoing deployments,
your continuous integration, continuous deployments by
leveraging Azure DevOps as the tracking for
managing your work items, your backlog as well as managing the release pipelines to get things from development to
test to production. To give you a little bit of idea of around the scale and usage that the Power Platform is currently
seeing as well as some of the growth that it’s
experiencing currently, and just looking at the size of the data that’s stored
in the Power Platform, 1.5 petabytes of data, that’s just a huge amount of data, as well as the monthly active users that are building
things on the platform, over 2.5 million building
things on the platform. As we get a little bit further, I’ll talk about how that
comes from all across the organization not just your traditional developers
of applications, and also the momentum around new features and improvements
that are coming that are a direct correlation to
feedback that Microsoft is receiving from the community and users of the application platform, and addressing things
that they need to be able to build the next
generation of application. In the next release wave, there is over 400 features
that are being added or improvements that are being
added directly based on feedback. When you’re looking at
a platform to enable digital transformation
in your organization, one of the important things
to consider is the technical skills that you
have across your organization. Now, this varies from
organization to organization. But predominantly, you can look at the left-hand side Word, PowerPoint, Excel SharePoint all being the traditional business
applications that users use in an organization and there are
a lot of users that do that as you can see by the trend
of the graph of the brown, highlighting that there
are a lot of those users. On the right-hand side,
you have JavaScript, HTML, CSS, C Sharp. All the languages and
technologies that you traditionally used
to build application. Now, when you think
about an organization, most organizations have
a very small amount of those that can do
the traditional development. Meaning that it’s not spread across the whole organization and that oftentimes where users have the best ideas come closer
to the business user, and we’ll talk about
that in a minute. What the Power Platform
does differently because of how it approaches
the low code approach, things that are very similar to the skills that you
would use to build Excel formulas as
well as to configure without having to do some of
the high code JavaScript, C Sharp to be able to do that, allows Power Platform solutions to be developed across the set
of the organization, and I’ll talk more particularly about how the different audiences in their organization can
participate in building the overall solutions as we
get a little bit further. One of the key things
the Power Platform does is empowered across the organization is ability to innovate
not just a single group or the more
technical developers, but it also starts at
the business user, the power users that understand
the business the best. They are able to bring
their ideas to life. Building a power app
or building a flow, something that makes their
day-to-day life a little bit easier. Some of those applications or
flows may grow up into help broader departments or in fact could impact the
overall organization, and that’s where it’s
important that they’re built on a scalable platform. A lot of times when Power users
start building solutions, they aren’t things
that can be managed by a larger group when that user
moves on or is no longer interested in maintaining it or
it’s grown to the popularity that needs a little bit
more governance around how it gets managed and rolled out. In the Power Platform, the IT staff or the
professionals that are hired to either build applications for the company or to implement the governance and managed
application accompany as opposed to the power users who traditionally have
an actual function and accounting or customer service or some business function
that they’re performing, the IT staff or professionals
that are hired or exist to basically implement
corporate wide applications. A lot of times this staff
can collaborate with the power users to build
more company wide applications. This is the group that may pick up
a application that was built by a power user when it
got more popular that needs a little bit more rigor
to its development. They may help aid in that ability
to get that application out to the full company rather than just something that’s
used by one or two users, rounding off some of the edges. Finally, the Developers. Developers are
the traditional developers that use more high code techniques, things like C Sharp, JavaScript, and they can unblock
complex requirements. Now, this doesn’t mean that
developers or people that would traditionally do this role can’t use some of the low code techniques. I come from a development background, and I think it’s important
to recognize that one of the things that
shifting and how we build applications for line-of-business use is that it’s important to pick the technique that’s appropriate for that type of application
you’re building, and for the function
you’re implementing. So developers need to be able to use the high code techniques
extended in Azure, but they also need to be
able to leverage some of the low-code techniques where it’s appropriate to solve that solution. Now, underlying all of this is the Power Platform
governance capabilities. So this is the ability to implement different
environments to support dev test production to isolate power users into
their own environment, and they have a particular
solution they’re trying to build as well as the governance to basically manage who can use what connectors as well as
the overall nurturing of users across the
organization to be able to leverage the Power Platform to
know how to build applications, and really enable everybody across the organization to innovate
on the Power Platform. Now, that we’ve covered how the Power Platform fits
into the vision and strategy in your
organization and how it can be leveraged across
to build solutions, let’s talk a little bit
more in depth and dive a little bit deeper into some
of the individual components. We’ve mentioned that
there’s Power BI, Power BI is focused on the analyze, PowerApps is focused on the acts. So in other words taking action based on some of the data
that’s presented to you, and Flow is really
all about automating. Now, these can be used independently. So you don’t have to store
your data in the Power Platform in the Common Data Service
that we’ll be talking about as
the data storage engine. Data can come from SharePoint, can come from Dropbox, can come from any other
third party system that has connectors or that you can build custom connectors too as
we’ll be talking about in the modules as we dive
a little bit deeper. Now, obviously these are
all best used together. When used together
in combination with the connectors that are
available for other systems, you can take Power BI to analyze, PowerApp to act and Flow to automate, and use them together to have an overall complete solution
that you implement. One of the things that
sets the Power Platform apart from other approaches
that you might have seen for building applications in
a low-code environment is the ability to have connectors
that connect to data and services. These are both Microsoft Services
as well as third party. You can also create
custom connectors. But these are
what abstract the APIs or application programming
interface and make them simpler to consume by people
building applications or building Flows in the system or to
bring data into Power BI. Now, these can be data
and services that are hosted in the Cloud already
or using the data gateway. These can reach back to
On-Premises assets and bring those into the Cloud solution that you’re building with
the Power Platform. Traditionally, when an organization builds a line of
business application or somebody comes up with a problem they want to
solve in an organization, you start with a blank
whiteboard and you draw out a data model starting from scratch, not leveraging
any existing definitions to make it easier to be able to do. One of the things that Microsoft
recognizes that leads to every solution having
a different way that they approach a lot of
the same Common Data, that’s where the Common
Data Model comes in. The Common Data Model is a set of unified definitions for some of the common business
characteristics, things like sales entities
service that really define the metadata associated with
those that fields the attributes, the relationships of how they connect together as well as the traits
that those entities have, and that is packaged up
as the Common Data Model. Now, the Common Data Model
Is not an implementation, it is just a schema specification
that is Open Source on GitHub. It comes with over 260 standard
entities out-of-the-box. It was inspired from Microsoft’s own applications what
they learned from implementing business applications
as well as working with independent ISVs
or companies that are focused on verticals to bring some of the vertical aspects to
the Common Data Model as extensions. That Common Data Model is
implemented by some of the services. For example, both the
Common Data Service that we’ll be talking
about in Power BI. Implement the Common
Data Model is a way to describe the data that they
store in a common way. You can actually use the Common Data Model also
for the definitions in your own internal systems
even if they’re not implemented in the Common Data
Service or Power BI for storage. You can take it for example, a SQL Database and implement some of the similar definitions and be compliant with the Common Data Model, making it easier for you to
interoperate and integrate with other systems by using
some of the common definitions. It’s also important to call out that using the Common Data Model
doesn’t preclude you from adding
your own custom aspects to the data entities that
are stored in there. To add your own fields, your own relationships and really
tailor it for your own solution. The Common Data Model just provides a structural common unified set
of definitions to start with that you can then evolve to implement
your own unique solution. The Power Platform
allows you to store data wherever you would
like to store it, and you can access it through
connectors to bring it into Power BI to PowerApps
or to Microsoft Flow. However, the Power Platform also
as a first-class data service called the Common Data Service or
oftentimes referred to as CDS. Modern line-of-business
applications have different types of data they store. Things that are relational, that needed traditional
relational characteristics, things that are more
document-oriented that need more of a document database as well as some that are
just simply more file oriented. Common Data Service is
a hybrid database that abstracts a lot of
those underlying details so you don’t have to worry about what storage engine is best for
the particular type of data. You worry about just
having modeling the data of the real-world entities
that you want to create. In this example, I’ve got permit somebody is making
a change to a property. They want to get approval
for their plans, and there’s relationships to the inspections that are
done for the work that was done based on those plans that they submitted as well as
who owns the building, and the notes that
the inspector put as they did the inspection on
that particular permit. Now, all of these can be done custom
where I implement the entity. But also the CDS database implements the Common Data Model
that we just talked about, allowing you to bring in some of the common sales service or
ISV applications into it. In addition, CDS also implements role-based security
down to the field level. This means that you don’t have to implement your own security model, you can take advantage of
the robust security model and the patterns that the
Common Data Service provides. You also have the ability to
do logic and validation at the data level that enforced across anything that’s consuming
the application. So whether a user is
building the application, they are pulling data into Excel
that’s connected to the CDS, all of those enforced that data
level rules that you put in place that match the business domain rules that you have for your application, and we’ll dive deeper into
building solutions with the Common Data Service as we
get into the tailoring module where we explain how
some of this comes to life and some of
the other benefits you get when you create an entity
including things like an API as well as
other eventing infrastructure that oftentimes solutions have to build custom using
developer resources just to do some of
the common plumbing that you need to build
an application on the platform. Because the Power Platform
can be used by users across the organization
to build solutions, it’s important to have built-in governance and
administrative capabilities to be able to manage
those types of environments. This includes
the ability to configure Azure Active Directory options including multi-factor authentication for use with the Power
Platform applications as well as getting
audit log and other usage analytics, and also putting in place data loss prevention
policies that can help put guide rails on for users that are building solutions to make
sure they don’t use connectors together that might result in data leakage out
of the organization. In addition to administrating
the applications using the portal, administrators can
also take advantage of PowerShell or the connectors
that can perform administrative action
allowing you to build your own power apps or
Microsoft Flows that administrate the platform
and implement your own custom governance that fits your own needs
as an organization. While of course, I think that
Microsoft is a leader in the low code development platform that’s why I’m recording this video. I wanted to highlight
that also Forrester, one of the industry analysts, also has recognized Microsoft as
a leader in this space as well. You can see the different players
and where Microsoft ferrets out. I think what really
influences is this is Microsoft’s ability to really
bring together a complete set of tools as well as to unlock for building more sophisticated things
that unlock even beyond that into the Azure capabilities
and to have that full stack of a platform that people
can bring to bear for solving their problems
at their organization. There’s a little bit and
talk a little bit more about building applications on
the platform whether you’re building on Office 365 customization on SharePoint all the way
to an ISV application. You’re building your applications using the PowerApps technologies. It’s a suite of designers
and studios that allow you to basically
build the application, leveraging the connectors to talk to the data or services that
your application has. Currently, as I mentioned
there’s over 250 connectors. But you can also add
your own to this, making it so that your application can talk to virtually
anything that you can put an API in front of and describe as a connector
into the platform. When you build a PowerApp, you’re building
a standalone application that can be used in the web or the mobile application players
that are available for PowerApps. This gives users access to the applications
wherever they might be. When you start building
an application, you can start with either a
blank canvas which gives you complete control over the user
experience and what’s on the screen that the user
interacts with or you can build from a model-driven
approach which starts from the data and builds a form over data application quickly enabling you to get something working
with the data that you’ve defined in the Common Data Service. In addition to having access
to the data sources to interact with data and
services from external items, you also have the ability to leverage device capabilities
such as the camera, the GPS, push notifications. You also have the ability
to use custom components. Custom components allow you
to have pre-built pieces that you embed in your application without you having to
build it from scratch, and we’ll see more examples
of these as we get into the tailoring and the developer
modules of this video series. PowerApps also allows you to easily
add Artificial Intelligence to your application without becoming a data scientist by
leveraging AI Builder, which is built into
the PowerApps portal. You’re able to train models and then leverage
those models with inside the canvas application
to do things like object detection without even
leaving the application. The PowerApps that you build can
be embedded in other applications allowing you to reach the user where they’re already
spending the time, not make them come to
your standalone application, whether they’re in Outlook, whether they’re using
a SharePoint forum, whether they’re in Power BI teams. This meets the user where they want to interact with the application, giving you the full ability to build an application that
leverages the connectors and other capabilities of PowerApps without leaving the app
that they’re embedded in. Now, let’s shift gears a little bit
and talk about Microsoft Flow. Microsoft Flow is at the heart of the automation that you can
do with the Power Platform. Lets you trigger events either
running off a manual triggers. Somebody says, “Hey,
I want to run this now by clicking
a button in the mobile application” or it can be triggered based on
a business event that happens from somewhere else within the Common Data Service or
even an external service. There’s over 400 triggers that come out-of-the-box that
allow you to start Flows and have them run plus you
can define custom events from external systems
using custom connectors. Once your Flow has been
triggered or started, you can use any of the other
connectors to interact with other systems or services as it
progresses through the Flow. Think of it as starting at the top, progressing to the bottom. Using those, you can do things like create a document in SharePoint, create a record in SAP. You can create a record
in Common Data Service. You could send a tweet on Twitter
using the Twitter connector. It really just depends
on how you want to orchestrate things across
the different systems. One of my favorite capabilities of Flow is the approval capabilities. How many times have you needed to
get approval for something from one or more people having to
custom build that approval Flow? Now, you can use
the approval built in where you simply state who’d you
need to get the approval from, what they’re approving, the
actions that they want to take, and the system takes care of
making that prompt the user, e-mail the user allowed them
to approve it through e-mail, and basically that
integrates into your Flow. So as your Flow gets to
that approval stage, it stops, waits for the approval
to happen or not happen, and then continues on
either the yes path or the no path depending on whether
the approval is achieved. Just like we talked about
with building our PowerApp, you can bring Artificial
Intelligence into your Flow as well, automating that interaction with the AI models that you build either
through directly using some of the Azure Cognitive Services or using AI Builder like we
talked about for things like object detection or form processing that you can do by
building the model in the PowerApps portal
and then leveraging the model that was built as part
of your Flow orchestration. Let’s talk about some of
the common scenarios where you might see Microsoft
Flow being useful. We already talked about
the automate approvals being able to do that across
data stores and services. Recurring processes, things that
you need to happen once a week, once a month, being able to have them trigger on a specific schedule. Even human interaction
things, process guidance, using the business process
flow capabilities, you’re able to provide
stages that you break a business process
into these majors to ages and then have steps that they must complete to
move to the next stage. Being able to stage-gate, them so not allowed them to
move to the next stage without completing the necessary steps
in the prior stage. Automated triggers allow you
to have logic that runs. Things that are orchestrated
after an event happens. Things like a record
created or a file is created in Dropbox or in OneDrive. Mobile users are able to
also get into the effect, kicking off one of the Microsoft Flows from
the mobile application, giving it context for
where the user is located or other important
information even including custom parameters that
they want to pass to give the flow information on what processing needs to
do in the background. PowerApps users can also kick off and launch of
Flow in the background. This allows you to use
Flow to offload work that otherwise they user might have to wait for the application complete, allow that Flow to run
in the background. In the tailoring module, we’ll dive in deeper into
what a Flow looks like, and in fact I’ll go
ahead and build one. But just give you an idea, essentially all Flows have a trigger, something that starts
the Flow and then they have one or more actions to find
what the Flow is going to do. Use the visual designer
to be able to do this. You can use drag and drop, copy paste to more orchestrate and move things around
within the Designer, and we’ll see all that come
together in the tailoring module. The final component of the Power Platform I wanted
to cover is Power BI. This is really all about analytics taking the data that you
have bringing it together and being able to produce
real-time dashboards or interactive reports that you can analyze and then decide what actions you need to
take to go from there. You can do queries against that data. Now, the data that you
bring into Power BI, can come from a variety
of different sources. Can be Cloud data, can be On-premise data, it can be telemetry, it can be real-time data
coming off a device. It can also be
more transactional data from a sale or a transaction that
the customer just completed. You can consume this from the Web, from mobile and even
embedded in a Canvas app. You can interact and have
your analytics right there side-by-side or the Canvas app
can be embedded into Power BI. So you’re starting to see how all of these components can be used
and interact with together. In fact, you can even
have a Flow that pushes data into Power BI to give some of that real-time
characteristics that you might want
to see in your data. The end goal when you work
with Power BI is to produce a nice pretty dashboard
like this that brings together data from
a variety of sources, and we’ve already talked a little bit about how
that could do that, and I’m going to talk a little bit
more as we continue on through this module about bringing in data
and some of the capabilities. That data can be live connected
or it can be scheduled refresh, where it refreshes
that aperiodic time. This allows you to
decide whether you want something to be alive
report or something that is as of last night or as of the last date of refresh
that you have on there. Data can come from
a variety of data sources. In fact, we’ll look
at how dataflows at a way to take and combine
those data sources and bring them in so they
can be reused across multiple Power BI
reports and dashboards. Normally, when you build
a Power BI report or a dashboard, you define the datasets
that it brings into that. If you were to define
multiple Power BI assets, each one you would start by
defining their own datasets, and they would do their own
preparation of that data. Where dataflows come in, is allow you to have predefined data source that you’re going to pull
in as your dataset. This dataflows come from
external sources just like datasets, but they allow you to do
some preprocessing on them. So rather than having
to do that work on each Power BI report or
dashboard you’re going to build, you can do that once and the dataflow and then bring
the dataflow in as your dataset, and then your reporting dashboard
is based off that dataflow, and you’re not having to redo some of the prep work over and over again. One of the things that’s nice when you’re working with the dataflows, dataflows have the ability
to work with mapping the data into the Common Data Model
compliant folders. So if a data source
for example came from another CRM system that wasn’t Common Data Service or
was in CDM already, you could map that into for example a CDM account or a contact and
then from the reports you build, it would look at it
just like it came from Dynamics 365 sales and service because it was mapped into
that Common Data Model format. When you leverage data flows, the data is pulled in and mapped
into Azure Data Lake Storage, and it’s stored in
Common Data Model format, and that allows it to not only
be accessible by Power BI, but it also opens it up for
being able to be used by other Azure services and other custom applications
you might build. So you might use this to ingest data into do some Azure Machine Learning, and then you might take the results
of some of that processing, and inject it back
into to accommodate a service for action within
the PowerApp or flow for further processing of the data
that you or insights that you’ve gained from that machine learning
processing that was completed. Oftentimes, when you first
adopt the Power platform, you may have data that’s
in external systems that you want to bring in
to the Common Data Service. You can use the data
integration capabilities of the platform to be able to bring that data in or synchronize
that data on an ongoing basis. The data integration capabilities leveraged Power Query to be able to do some of the mapping and
transform of those data sources. You have a number of
data sources everything from SQL, to Azure tables, to Salesforce, IBM databases
that you can bring data in, transform it, and bring that in. There’s templates for some of
the common sources that you can use things like Salesforce to be able to bring data
into the platform. Once the data is integrated
into Common Data Service, you can use all the tools that are available to the Common
Data Service on that data. In the extending module
of the video series, we dive deeper into the high code developer support that the platform
has available to it, but they’ve really boiled
down to client extensions, things that developer can do
to extend the user experience, as well as server extensions, things that you can do
to really implement custom code that runs as part of the eventing mechanisms
of the platform. For example, when
a record is created, you can automatically
run some custom code to perform some additional
business logic, and that business logic becomes a natural extension of the platform, just like it was almost built
as part of the platform itself, providing a deep integration for that custom code
into the platform. You can also leverage integration. This is through publishing
events outside through Azure Service Bus or to
Webhooks outside the platform. Developers also have
a complete Rest API that they can work with to do
pretty much automate anything that they want through the API that you could do through the portals with either data or customization
characteristics of the platform. We’ll dive a lot deeper into
this in the third module on extending where we cover the
developer support in more detail. From an application lifecycle
management perspective, it’s important to think about the overall life of the
application from building it to basically getting it deployed and managing it in an ongoing basis. This starts with when you’re
building a solution and the capabilities that come
around the solution framework. The solution framework is the container that all
your customizations, everything that you’ve customized to build a solution or stored in, that solution is used to
move from Dev to test to production as part of
the lifecycle of the application. All of this can be
automated and tracked using Azure DevOps or your other
favorite tools that’s similar to that using some of the tasks
that are available or APIs that are available to
automate the platform on there. In the tailoring module, we’ll dive deeper into how some of the solutions work to track
the customizations that you’re working and how that works
throughout the lifecycle of the application as it’s deployed
from Dev to test to production. From an update/upgrade perspective, you can think about updates as happening on an ongoing weekly basis using a safe deployment practice where they deploy to
one of the stations, there’s multiple stations,
and those rollouts. So you may find depending on
where you’re located in the world that you may get things a little bit earlier than the other
parts of the world. That’s all part of
how the weekly updates rollout across the geographic areas. Twice a year starting
in April and October, there are major release waves. These are the more disruptive
things that might have a change in the user interaction, whereas the weekly updates
are intended to be either fixes or things that do not impact how the user visually interacts with the system
that’s on there. As part of the April
and October releases, you’ll find that
several months before, there are published release notes
that highlight the changes. These detail out what is planned
and when they’ll be landing from that April to October time
frame or October to April. So think of them as a wave of the features that roll
out during that time, and all of them bring things
that have been requested by users or enhancements that bring
great value to the platform. It’s important to understand
that the Power platform follows the trusted Cloud principles
that Microsoft has adopted really
focusing on security, privacy, control, compliance,
and transparency. All of this is at the forefront
of all the decisions they make on enhancements as well
as management of the platform. This is detailed out on
the Microsoft Trust Center. If you want to drill in, you want to find out
the certifications or the attestations that the platform has or understand how privacy is handled on the various
components of the system, you can find that on
the Microsoft Trust Center. Well, that gets us to
the end of our overview, but I wanted to leave
you with a couple of actions to take as you continue on. First is some learning resources. So if you want to dive in deeper, Microsoft Docs has
all the product documentation on it. Microsoft Learn has Learning Paths
that are appropriate for learning more about PowerApps
and Flow as well as Power BI. If you continue on with
us in the video series, in the second module, tailoring, we’ll look at a little bit
more in-depth, look at building applications and
building flows on the platform. Then, in the final third module, we’ll look at some of
the developer techniques can be used to further extend
the platform as well. Thanks for joining
us in the overview. I look forward to seeing
you in the next module.

Comment here