Power Platform Licensing - A Jigsaw puzzle?

One of the most common impressions that we gathered so far of Power Platform to be used as Rapid Development (RAD) framework is that, it comes free with Microsoft 365 (a.k.a. M365 and formerly  Office 365) plans. At least the developers, architects and business users (power users in the world of Power Platform) of M365 got that flavor because Microsoft had let us enjoy its easy availability with the M365 plans. We were able to connect with both Microsoft and non-Microsoft data sources in cloud and on-premise environments alike with a range of in-built connectors and/or using HTTP connectors, developing custom connectors. 

But with the inception of the premium plans which were initially P1 and P2, we found a green box, likestarted appearing beside many connectors. Then we came to know from Microsoft's release notes that unlike many connectors which used to come free with the M365 plans earlier, then became paid. That means organizations had to buy additional licenses to use them.

Then as the technology kept evolving, there were more restrictions being introduced and users/developers started getting "API limit error". This is because Microsoft also introduced API limits. That means operations which use connectors, call APIs, initializing variables with values, flow calls etc. all account for the API limits that Microsoft introduced. This means even if you buy licenses, there is more to it. So how do you configure scheduled flows which run unattended, keep monitoring your sites and environments? Jobs are one of the prevalent requirements, these days, when we keep modernizing and automating. 

Isn't that all a jigsaw puzzle? Well, it is, if your knowledge purview of Power Platform licensing does not cover every nook of it. I have seen clients walking out of signed contracts calling Power Platform a costly affair, either because of their ignorance of how it is priced or because of inadequate consulting done by the vendors who propose to modernize their workspace using Power Platform. In most cases it is the latter.

This is why, you need a rock solid understanding of how licensing works to provide the most optimal solution around Power Platform, to make the fullest use of this RAD framework from Microsoft. Only then will you be able to convince your client that Power Platform indeed helps in cutting down budget and one of the best of its kind in the industry from every aspect.

This article aims at covering most of it with the help of some very apt case studies that summarizes and simplifies Power Platform licensing for you.

Out Of Scope 

This article does not cover UI flows, Power BI, Power Virtual Agent. Stay tuned for future articles covering these topics.

Prerequisites

First you need to take a look at the following pages from Microsoft documentation to understand the pricing slabs, restrictions, add-ons, etc.

• PowerApps plans - P1 and P2 plans (discussed above) are now replaced by Per User and Per App plans. See https://powerapps.microsoft.com/en-us/pricing/ to learn more.
• Power Automate plans - Visit https://flow.microsoft.com/en-us/pricing/ to know about the pricing options.
• API limits - See https://docs.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations#request-limits-based-on-user-licenses to understand the API limits.
• Capacity Add-ons - See https://github.com/MicrosoftDocs/power-platform/blob/main/power-platform/admin/capacity-add-on.md to learn more.

Decision Making

First of all, there are few questions that you would need to answer to be able choose the right plan for your client, as follows - 

1. How many flows will be running in your organization, approximately?
2. What type of flows are they? Are they automated or scheduled or instant?
3. How many scheduled flows do you need to run, approximately? How often will they run?
4. How many automated and instant cloud flows do you need? How many users will be using them?
5. What all data sources you want to connect with? Are they all native M365 services or would you be needing Premium connectors?
6. Do they all have built-in connectors available in Power Platform? 
7. What type of users will be accessing your environment? Are they internal or external to your organization or is it a combination of both?
8. Do you need to build a portal?
9. Do we need to worry about large number of API calls?

 Plan Selection Matrix

Sl No	Requirement	Plan Suggested
1.	Native Data Sources Only?	M365 E3/E5 Plan
2.	PowerApp Only - At least one premium connector used?	PowerApps Per User/Per App Plan
3.	Large no. of users and limited no. of apps?	PowerApps Per App Plan
4.	Large no. of apps, but limited no. of API calls?	PowerApps Per User Plan
5.	Estimated high no. of API requests/flow calls from apps?	App Passes under Capacity Add-ons
7.	Run Scheduled Flows Only? No limit to API requests.	Power Automate Per User Plan assigned to a service account
9.	Run Instant/Automated Flows with potentially high no. of API requests?	Power Automate Per User Plan
10.	Run limited no. of shared flows with no limit to users consuming them and no limit to API requests?	Power Automate Per Flow Plan

Case Studies

1. I have 5000 internal users, who will potentially use apps to be developed such that data operations will happen on M365 workloads only like SharePoint Online, OneDrive For Business, Microsoft (MS) Teams and Planner.

Solution

This case typically falls in bracket of question # 5 (see "Decision Making" above). Answer to this question will be Sl. # 1 in the Plan Selection Matrix (see above)

"M365 workloads only" means M365 native data sources being used. We do not need any premium connector. 

Answer to the puzzle is -

• 1 M365 enterprise plan like E3 or E5 for every user 

2. I have a hybrid deployment, that uses M365 for workspace modernization. I have 5000 internal users, who will potentially use apps to be developed such that data operations will happen on M365 workloads like SharePoint Online, OneDrive For Business, Microsoft (MS) Teams and Planner. In addition, there will be 2 jobs that will import data from an on-prem SQL Server instance to SharePoint Online, that will eventually be visualized as Power BI dashboards and charts. My SQL Server on-prem database size is ever-growing.

Solution

Key excerpts from the above use case are -

• Data import happens in M365 from on-prem SQL Server. So we need to configure data gateway, which is only available with premium plans of PowerApps/Power Automate.
• Data import to SharePoint Online is via jobs. This means it is a scheduled sync and NOT real-time. Therefore, 2 scheduled flows should suffice.
• 5000 internal users will be using app, that reads data from native M365 workloads. So they can very well be licensed by the standard M365 enterprise plans. (see Sl. # 1 in the Plan Selection Matrix)
• Scheduled flows' calls of SQL Server connector will never exceed 5000 mark stipulated for a PowerApps Per User Plan (See "Prerequisites" section, above)
• Ever-increasing database size is also not a matter of concern as we are bringing in data to SharePoint Online, an integral component with M365 plans.

So answer to the puzzle is -

1. 5000 M365 E3/E5 plans
2. 1 PowerApps Per User Plan for a service account for running the 2 flows

3. I need to develop an app that will use Microsoft Azure cognitive services like Conversational AI built on top of a curated knowledge base. The app needs to be deployed to MS Teams as a channel app for members of the channel to use.

Solution

This one is pretty straight forward. We shall use MS Azure QnA Maker connector in a flow in Power Automate and call the flow from a PowerApp canvas app. The PowerApp will then be added as a tab in a MS Team channel.

This corresponds to question # 5 under "Decision Making" and Sl. # 2 under section "Plan Selection Matrix", where your QnA Maker connector is a premium connector. The app will run in user context. 

So simple answer to the licensing puzzle is -

• PowerApps Per User Plan for all the members of the channel.

4. I am an admin who wants to loop through all SharePoint Online sites in my tenant and generate a permission report.

Solution

This is a typical case where we will either need to develop a custom connector to enumerate through all SharePoint Online sites (check my post https://microsoftcloudautomation.blogspot.com/2021/08/powerapps-custom-connector-to-enumerate.html) or need to post HTTP requests from a scheduled flow to generate permission extract, that too as a repetitive task. This has potentials to even exceed 5000 API requests limit a day, if it is a daily extract and no. of sites in the tenant is large.

So this corresponds to Sl. # 7 under "Plan Selection Matrix" and questions # 3, 6 and 9 under "Decision Making" (see above).

Answer to the puzzle is - 

• Power Automate Per User Plan to be assigned to a service account, that will run the scheduled flow.

5. I am a site admin who wants to be notified whenever there are documents uploaded or modified to a document library with some predefined criteria or pattern, due to security reasons. I have 3,000+ employees in my organization who do frequent uploads and changes in this library.

Solution

Here, the admin wants to monitor activities with files in a SharePoint library. As you can see that the library is open to all users in the organization and user count is 3000+, chances are high that there will be more than 5000 operations a day. Hence, if we create a real-time notification and extract activity log, that will lead to 5000+ API calls. On the flip, if we design a scheduled flow (which we can afford to do here, as it is a background process and extracts downloaded thrice or four times a day generally suffice monitoring purpose), we can still restrict API calls to only 3-4 times a day. That makes a whole bunch of difference when pricing is to be taken into consideration.

Also there is no built-in connectors for activity logging and monitoring. We need to consume #Microsoft365 Activity Management APIs. That needs us to make HTTP calls or build a custom connector (#customconnector). Whichever path you tread, you need to a premium connector.

So this corresponds to our questions # 2, 5 and 9 under section "Decision Making". Then, under "Plan Selection Matrix", Sl. # 7 also helps us coming to a decision point.

So answer to the puzzle is - 

• 1 PowerApps Per User Plan assigned to a service account or to the admin's account will suffice

6. I want to create a portal that will be accessed by 5,000+ external users who are authenticated by Azure AD. The portal will have canvas apps embedded that will also be externally faced. 

This is a typical case of PowerApps portal being accessed by authenticated external users. 

Answer to the puzzle is -

• Portals with login capacity is the required plan here. This gives 100 login session per month. So an estimated 51 plans should suffice for this requirement. (Visit PowerApps pricing page, referred under "Prerequisites" section.)

Conclusion

I really hope the aforesaid was helpful, as this indeed puzzles most of us who struggle to choose the right plan for our customers. I tried collating few of the trending use cases above. Comments with more use cases are welcome. I shall try my best to answer them.

Stay tuned for more case studies! 😊

PowerApps Custom Connector to enumerate SharePoint Online sites

Component Architecture

Introduction

With the introduction Power Platform, business users (a.k.a. power users) can now develop apps and automation solution with some basic programming concepts using a no-code/low-code platform. Power Platform is known to have built-in connectors for various Microsoft and non-Microsoft service workloads, both on Cloud and On-prem, that widens up the reach for the Power Users to try their hands in building applications using a wide variety of technology stacks.

But there are still some grey areas where built-in connectors are not available and we have to count on RESTful APIs that are exposed to be consumed, considering certain factors like, authentication mode, request header and body etc. Here lies the essence of custom connectors, which can be leveraged across all components (like PowerApps, Power Automate, Power BI, Power Virtual Agents) in a Power Platform environment, for achieving those integrations, data ingestions, CRUD operations etc. where built-in connectors fall short.

Objective

Enumerating SharePoint Online sites in Microsoft 365 tenant is a frequent requirement in various applications being developed encompassing Microsoft collaboration on cloud solution. Conventionally, developers have used PowerShell, C# and client-side scripting in achieving this. But what about Power Platform? Do we have suitable actions in SharePoint connector? These are the questions started making rounds in my head, when one of my recent client requirements needed this and I eventually got bewildered to learn that we do not have a built-in connector for this, along with several other frequent and complex operations we do on SharePoint Online.

I ended up building a custom connector that calls Microsoft Graph APIs, exposed by SharePoint Online. This article is a step-by-step walkthrough that will help you achieve what I did in no time. You can then use the custom connector in all the components in Power Platform.

Prerequisites

1. You need a minimum Power Platform Environment Role “Environment Maker” (see https://docs.microsoft.com/en-us/power-platform/admin/database-security to learn more on Power Platform Environment user security)
2. You need an Azure AD App Registration (see https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal to learn how to create Azure AD Application and service principals). For creating this, you can make use of your free version of Azure AD that comes with your Microsoft 365 plan, as this is not a premium feature.
3. Knowledge in Power Platform (see https://docs.microsoft.com/en-us/learn/paths/power-plat-fundamentals/ to learn more)
4. Knowledge in RESTful APIs
5. Knowledge in Microsoft Graph APIs (see https://docs.microsoft.com/en-us/graph/overview to learn more)

Steps

The steps below are grouped under relevant sections (two broad categories "Azure AD App Permission" and "PowerApps Studio"), highlighted and number marked, that signifies the sequence of actions to be taken to achieve the objective (sated above).

Azure AD App Permission

Your Azure AD App registration details, as follows, need to be captured in this step for later use.

Web Redirect URL 

Go to Azure portal (https://portal.azure.com/) > Azure Active Directory > App registrations. Then click open your app registration. Finally 

1. Click on “Authentication” (see Fig. 1).

2. Then under “Web” > “Redirect URIs”, you have the URL to copy (Fig. 1). Save it somewhere, as you will need it later steps.

Fig. 1

Client ID

In your App registration click on “Overview” (# 1 in Fig. 2) to get the Application (client) ID as shown below. Click on the “Copy to clipboard” button (# 2 in Fig. 2) to get it copied. Save it somewhere, as you will need it later steps.

Fig. 2

Client Secret  

Click on “Certificates & secrets” (# 1 in Fig. 3) and then “Value” under “Client Secrets” (# 2 in Fig. 3). Copy and save it somewhere so that you can use it later steps.

Fig. 3

API Permissions

Finally under “API permissions” (# 1 in Fig. 4), select the permission as shown in point # 2 in Fig. 4. And then you must “Grant admin consent for <your organization name>”, as shown in point # 3 in Fig. 4.

Fig. 4

PowerApps Studio

Go to PowerApps Studio > “Custom Connectors” (# 1 in Fig. 5) under “Data”. Click on “New custom connector” (# 2 in Fig. 5) and then “Create from blank” (# 3 in Fig. 5).

Fig. 5

Give a name to your connector as shown in Fig. 6 and click on “Continue”.

Fig. 6

Then, in the following screens configure each tab (i.e., “General”, “Security”, Definition”, “Code” and “Test”)

General Tab

1.       Upload connector icon – Select a suitable image from your local file directories.

Fig. 7

2.       Configure “Host” and “Scheme” values as shown below in Fig. 8.

Fig. 8

Security Tab

Authentication Type - Select value as “OAuth 2.0” as shown in Fig. 9. 

Fig. 9

Configure “OAuth 2.0” as shown in Fig. 10.

Get Client ID and Secret from Azure AD App Registration step (see above). The rest of the configurations can be found from the below screenshots (Fig. 10 & 11). Keep all the values exactly same as the screenshots.

Fig. 10

Fig. 11

Definition Tab

Firstly, click on “New action” as shown below to create your connector’s action. Note: You can add multiple actions in your connector by repeating the below steps for every action you add.

Fig. 12

Then, set name, description and Operation ID as follows.

Fig. 13

The configure “Request” details as follows -

• First click on “+ Import from sample” (# 1 in Fig. 14).
• Then, select “Get” as “Verb”. You could select other verbs for CRUD operations. Here, our goals is to get all sites in your tenant. So it is read operation that can be achieved by “Get” verb.

 

Fig. 14

• URL: https://graph.microsoft.com/v1.0/sites?search=*&$select=displayName,webUrl,name (# 3 in the above screenshot) for this use case is given below. This RESTful MS Graph API Url will return all sites in the SharePoint Online tenant with metadata as Site URL, Site Display Name and Site Internal Name.
• Finally click on “Import” button.

Then, configure “Response” details as shown below. Click on “default” and then on “Import from sample” as shown in below screenshots (Fig. 16 and 17).

Fig. 15

Fig. 16

Then, fill up the “Headers” and “Body” as shown in the below screenshot (Fig. 17) with the values retrieved from Graph Explorer (see Fig. 18 and Fig. 19)

Fig. 17

The “Body” in the above screenshot can be retrieved from Graph Explorer > Response preview as shown in the below screenshot (Fig. 18):

Fig. 18

The “Headers” in Fig. 17 can be retrieved from Graph Explorer > Response headers as shown in the below screenshot (Fig. 19): 

Fig. 19

Code Tab

Fig. 20

As shown in the above screenshot, keep “Code Disabled”.

Test Tab

Fig. 21

Do not forget to click on “Create Connector” before being able to test the connector, that you just created. 

Calling connector from PowerApps canvas app

Finally, to make use of the custom connector you created in the above step, follow the below steps:

• Open PowerApps Studio from https://make.powerapps.com/
• Click “Apps” in the left navigation bar.
• Click on “New app” and select “Canvas”.
• Provide a name of your app in the “App name” textbox and select one of the formats from “Tablet” or “Phone”.
• Follow the numbered steps as shown in the below screenshot (Fig. 22)

Fig. 22       

• Add a “Drop down” control from “Input” group of controls in your left toolbox.
•  Set the “Items” with the formula as shown in below screenshot (Fig. 23) and save your app.

Fig. 23

• Finally preview your app to see the site display names being enlisted when you clik on the dropdown control as shown below in Fig. 24.

Fig. 24

Conclusion

If you have reached here, that means you have successfully created a custom connector that enlists all SharePoint Online sites in a Microsoft 365 tenant and added a formula to bind them in a PowerApps app.

See you in my next article. 😊