Microsoft has released its guidance and best practices: PowerApps and Microsoft Flow Governance and Deployment Whitepaper. It’s a great document, I highly recommend it for anyone considering PowerApps, Flow and/or Common Data Service (CDS) for their enterprise.

I find that a document of this stature to be intimidating to engineers, admins, and IT pros. It’s 66 pages of important information to consider before making a decision, and frankly who has time for all of that? I do! Train rides are awesome… I thought I’d write up a summary, or cliff notes, version of the document.

Please let me know what you think if you have read it, did I miss some important points from the document? Remember, this is a summary and I encourage you to read the original document if you determine this summary is compelling enough for you to do so. Don’t take my word for it. I will be ignoring most of the CDS content, since I have to pull something out to lighten the load, and frankly, not many enterprises are looking to adopt CDS yet.

I do have my own commentary added at the end, and I do my best to not add commentary throughout the document.

Important side note, I will do my best to keep this up to date, however, Microsoft can change the document at any point in time. Let me know if I’m missing anything new!

What to expect:

• Intro
• Environments
• PowerApps
• Microsoft Flow
• Connectors
• Licensing
• Security
• DLP
• Management and Monitoring
• Deployment Scenarios
• Application Life Management (ALM)
• Compliance and Data Privacy
• Support and Learning
• What you won’t find in this document

Intro

Crawl, Walk, Run

The doc kicks off with some good advice (Page 5).  Take it slow, check out what’s in play now, set up a basic administrative flow. Then start to plan for your environments and security, implement, then rock and roll!

What are PowerApps and Flow?

If you’re still new to these capabilities, page 6 through 8 have a good intro on what they are and how they work with each other. There are also some usage scenarios to continue to help us understand what they do.

Environments

(Page 8) “Environments are containers that administrators can use to manage apps, flows, connections, and other assets; along with permissions to allow organization users to use the resources. Environments are tied to a geographic location that is configured at the time the environment is created. Environments can be used to target different audiences and/or for different purposes such as dev, test and production. The actual number and purpose of environments in your tenant is up to you as an administrator.”

Each environment has a unique set of security roles, Administrator and Maker. Makers can create and share apps, connectors, gateways, etc. An environment can be created for any need as you see fit. You could do a typical application life cycle, like Dev, Test, Prod. You can do it regionally, to keep apps closer to your users, like North America, Europe, Australia. You could create environments for groups of users, like HR, Finance, Sales, etc. Anything you want to do here you can.

(Page 10) “Each tenant will have a default environment created automatically in the region nearest the Azure Active Directory (Azure AD) tenant. This environment has a few unique characteristics from other environments that you create. This environment can’t be disabled or deleted. All tenant users are added automatically to the maker role for the default environment and you can’t remove them from that role. They are not however added automatically to the environment administrator role. This makes the default environment the perfect place for people to build personal productivity apps and flows. The default environment is also the only place you can currently create gateways to connect to on premises resources. So, if you have an application that needs on-premise resources the app, its connector and the gateway must be created and run from your organization’s default environment.”

Environment-al impacts

Environments look promising, but there are some impacts you need to keep in mind. First, your users will have a heck of a time managing their own apps and such across the environments. When users navigate to PowerApps, they cannot see a single list of all apps, across all environments. They’ll have to switch environments to find their apps. (Page 11).

As you move apps from environment to environment, you will have to reconfigure the data connectors each time. (Page 12) Also, there is no easy way to move an app from one to the other. You have to download it to your machine, then upload it into the next environment. More on application lifecycle a little later.

PowerApps

(Page 16) There are two types of PowerApps you can create: Canvas Apps and Model-Driven Apps. Canvas apps are your typical app, mobile friendly, SharePoint list form, etc. Model-driven apps work with CDS, soooo I’m not talking about it.

(Page 17) PowerApps are versioned automatically when saved, but only available to users once the app is published. Only one version of the app can be published at a time.

(Page 18) Your apps can be exported and imported into environments and even different tenants.

(Page 19) The Admin Center at admin.powerapps.com can show you which apps exist in each environment.

Microsoft Flow

(Page 19) “Microsoft Flow is an online workflow service that allows automating tasks across multiple services using connectors. Flows are started when a triggering event occurs, this could be a record is created or a scheduled execution, or even a button click from the Microsoft Flow mobile application. Once triggered, the flow proceeds to execute the actions in the flow. Conditions are used to guide the flow to the proper actions. You may find that it helpful to create some flows yourself to support your administration of your company’s PowerApp environments. ”

(Page 20) Only owners have access to their Flows, and a Flow can be shared with other people, making it a Team flow.

(Page 20) If you’d like to learn more about Flow, and how it compares to Azure Logic Apps, there’s a great write up. The biggest thing to keep in mind is that “Microsoft Flow is built on top of Logic Apps”.

(Page 21) Like PowerApps, Flows can be exported and imported across environments and yes to other tenants. They can also be exported in a Logic App format for importing into Azure. If your Flow needs more capability and the umph of Azure Logic Apps, you can easily upgrade your flow.

(Page 21) You can view what Flows exist through the admin center for the environment.

Connectors

(Page 21) “Connectors are essentially proxy wrappers around the APIs provided by services that allow Microsoft Flow, PowerApps and Logic Apps to easily interact with the service. Connectors can be either public or custom. There are currently over 200+ public connectors that can be used by all organizations. Examples of public connectors are Office 365, Common Data Service, Twitter, Dropbox and more. Custom connectors are defined in the context of an environment and are only available to apps and flows within that environment. Connectors make triggers and actions available that can be used by the apps and flows. Triggers are used by flow or Logic Apps to start the execution of the workflow. Actions are used by apps and flows to perform a defined set of actions during execution.”

(Page 22) Connectors are automatically included in your PowerApps. When sharing your app, for most connectors, the user accessing the app will authenticate against the connectors using their own credentials. When sharing a Flow (Page 22) the credentials of the creator, as the flow was configured, is also shared. This means your co-owners will have access to the creator’s credentials. This can allow escalation of privileges beyond what is intended.

(Page 22) There is one exception to the above sharing security risk with Flow, and that is with Run-only flows. These flows are shared with users, and like PowerApps, the user running the flow uses their own credentials within the Flow.

On-premises Gateways

(Page 26) “The on-premises gateway allows PowerApps and Flow to reach back to on-premise resources to support hybrid integration scenarios.” If you’re looking to learn more about the gateway, there are many pages here explaining more about setup and usage.

Licensing and License Management

(Page 29) “Organizations can obtain licenses by either licensing Microsoft PowerApps or Flow specifically or by it being included in the license of another Microsoft cloud service offering. For example, both Office 365 and Dynamics 365 provide entitlements for PowerApps and Microsoft Flow. As with most Microsoft licensing, you can mix and match for users as appropriate giving some additional entitlements.”

(Page 30) There are two standalone licenses available, PowerApps P1 and PowerApps p2. Some data connectors require one of these licenses, and some other capabilities like environment management, require additional licenses.

(Page 31) Each license also has impacts to your Flows: number of runs ranging 750 to 15,000 per month and trigger frequency from 15 minutes to 1 minute. Your Flow counts accumlate for the entire organization. This means 100 Office 365 users will share a pool of 200,000 flow runs.

(Page 32) You can check user licenses in the admin center.

Security

(Page 35) “In this section of the paper we are going to look at how the PowerApps platform handles security from user authentication to authorization which allows users perform actions with data and services. Conceptually, security in the platform is there to ensure users can do the work they need to do with the least amount of friction, while still protecting the data and services. Security in the platform can be implemented as a simple security model with broad access all the way to highly complex security models where users have specific record and field level access. The following is a high-level look at how a security model is implemented in PowerApps”

Data Loss Prevention (DLP)

(Page 40) “Data Loss Prevention (DLP) policies that help protect organizational data from unintended exposure, are available for administrators to create. They can act as guardrails to help prevent users from unintentionally exposing the data. DLP policies can be scoped at the environment and tenant level offering flexibility to craft policies that are sensible and do not block high productivity.”

(Page 41) DLP works by separating your data connectors into two groups: business data only and no business data allowed. By default, all connectors are in the latter group. This feature allows admins to separate business data sources from non-business, like separating Salesforce and Twitter. Once separated, if a user creates an app or Flow with a connector from one group, they cannot add a connector from the other group. Therefore, people can’t tweet your every sale lead from Salesforce.

(Page 43) There is some great insight into how to think about your DLP policies for smaller and larger environments.

Management and Monitoring

(Page 45) There are three categories of tools you can use to manage and monitor your environment(s).

(Page 46) Web admin portals are available for typical administrative activities. There are a list of links and more information available

(Page 49) PowerShell is available for those of us who love to type, or looking to automate certain tasks. There is a list of links to more information on PowerShell.

(Page 51) Connectors are available for Flow Management and can be used in monitoring. There is a list of connectors and possible use cases.

Deployment Scenarios

(Page 52) “Now that you have read through the platform architecture section and the data protection concepts, and have a good grasp of all the individual components, let’s look at some scenarios and how you might handle deploying them. This assumes you created some default data loss prevention policies like what we suggested in the compliance and data protection section of the document. These scenarios represent possible deployment configurations but are not the only ways you could deploy the given scenario. Use them to inspire how you want to handle things in your organization.”

Application Lifecycle Management

(Page 54) “Application Lifecycle Management (ALM) is important as the applications your organization builds becomes more complex and as more of your company depends on their stability. ” There are some guiding questions in what to consider in defining your ALM.

(Page 56) Moving your solution from an environment to environment is a very manual process, and requires you to export then import as you go.

(Page 58) Something important to keep in mind: “PowerApps canvas applications need to be periodically republished for best performance and stability. About every six months you should re-publish your deployed PowerApps canvas applications even if they haven’t changed. This ensures the application picks up the latest runtime changes in the environments.” When your apps are published, the version of PowerApps at that time is in your app. The PowerApps version is not automatically updated in your published versions.

Compliance and Data Privacy

(Page 60) “To help your organization comply with national, regional, and industry-specific requirements governing the collection and use of individuals’ data, Microsoft provides the most comprehensive set of compliance offerings (including certifications and attestations) of any cloud service provider.” This section dives into the Microsoft Trust Center, data geolocation, data protection, GDPR, O365 security and compliance center, and Microsoft Flow audit logs.

Support and Learning Resources

(Page 64) “In this section let’s look at some of the options for gaining further knowledge, and if necessary getting support.” A great listing of articles, resources, learning, sites and more to get support.

What you won’t find in this document

I tried not to add my own commentary above, as I wanted it to be a read out from the Microsoft documentation. But I can’t sit quietly either. There are some things that are important to IT that are missing completely. I hope to cover some here.

Service accounts

Service accounts don’t exist, in the truest meaning of a service account. Traditionally, an IT organization would have service accounts available to run applications on, grant generic access to services, impersonate, or otherwise to support applications. Since the Power Platform runs in Office 365, there are no service accounts.

The impact is that all of your connections in your Flow will use the owner’s account. If your Flow sends an email, then the email is sent from the owner’s account. If that Flow is a Team Flow, then everyone who has permission to Flow has permission to the original owner’s account.

The best workaround for this is to create a generic account in O365, license it (yes, you’ll have to pay for it), grant it permissions as needed and use that in your Flows. Basically, you will create a full-fledged user as a service account.

PowerApps doesn’t have this issue, as when PowerApps run, it runs under the credentials of the user running it. The creator’s account is not used.

Application Lifecycle Management (ALM) and Software Development Lifecycle (SDLC)

The document does a great job in defining what is possible for ALM, and sadly it’s very manual. CDS introduces a cleaner more efficient way to provide continuous deployments from environment to environment, but at a high cost. Maybe this isn’t what is missing in the document, more like what’s missing in PowerApps and Flow.

PowerApps seems to be focused on a single “developer” at a time. That developer is targeted to be a business power user: someone who knows the data and the business and can create the app themselves. This is the beauty of the PowerApps. What happens when you need more people editing the app? PowerApps and Flow don’t support co-authoring, as we’ve come to love in Office documents. There are ways around this in PowerApps, like copy/paste screens and components from app to app, and using the new reusable components.

For Microsoft Flow, I don’t see any way around this, each Flow can only have one editor at a time. You could create multiple flows and have them call each other, but then your Flow runs will count up faster.

As enterprises consider this platform for an enterprise-wide application, versus small implementations or a functional group or department application, it’s critical to keep in mind the limitations in ALM/SDLC. For smaller projects, it may not be a big deal. Creating an app in a few hours and immediately provide value may far exceed the need for a real ALM.

Governance

The page that hosts the document is called “PowerApps and Microsoft Flow Governance and Deployment Whitepaper“, though there isn’t a lot of governance in this document. It does a great job covering deployment details, scenarios, and considerations. But it’s lacking governance best practices. My above two missing items may fall more under governance than deployment, and that may be why we don’t have them in this doc. Maybe I need to make a governance document. We’ll see.

What else?

What do you think is missing? What hot questions do you have? Let me know below and let’s see if we can get some answers.