PowerApps?

[JohnJStraumann]

Hello all:

I am an experienced developer but new to PowerApps. In my past experience platforms like PowerApps seem great at the beginning, but very quickly the demands and flexibility required to build a fully functional app outstrip what the platform can do. I'd appreciate any input folks have on building Enterprise grade applications with Power Apps?

For example, let's say I wanted to build a Canvas Power App that sets up a User Login screen for both IOS and Android, and the User data is stored in Azure SQL Server connect to an existing web portal, which uses .NET authentication and authorization. Any input on how this could be done?

Also, can anyone provide feedback in the licensing for the Platform? The information I have found is confusing, one source says an Office 365 license is needed, another says standalone licensing is available, still another says additional licensing is required for connecting to SQL and other add-ons.

Thanks in advance for any and all input!

John.

[Pstork1]

Lets handle the licensing question first.

There are basically three different types of licenses available for Power Apps.

• The "seeded" license that is included with Office 365.  This covers the use of Power Apps with any of the standard connectors. In your case this isn't enough because SQL is no longer a standard connector as of October, 2019. 
• The Per App license, retail $10/user/month, this covers up to two related apps that use premium connectors like SQL or CDS.  This can be less expensive if you only have a few apps that are run by a lot of people in your organization.
• The Per User license, retail $40/user/month, this covers an unlimited number of apps that use premium connectors.

Each user who runs an app must have a license that covers all the connectors used by that app.  So if you want to use SQL you'll need either a per App or per User license.  The Office 365 license isn't enough for that.

Now on to authentication.  There is no need to build a login screen for a Power App.  All Power Apps run in the context of the Office 365 cloud, so your users will need to login to Office 365 to run the app.  For most data sources that authentication is what provides access to the data. For SQL you will connect to the SQL server using a connection account.  That connection account will determine what data your users have access to.  Power Apps is not a security layer, so there is no real provision for creating a login screen or tying into .Net Authentication.

Hope that helps.  Let me know if any of that is unclear or you have additional questions.

[JohnJStraumann]

Hello:

Thanks for your note and I love your company name! LOL

This is great info, just 1 clarification on the License, EVERY user must have a PowerApps License and an Office 365 login? I have potentially thousands of users, so even if I use an example of 1000 users at $10/month, that's costly! And then if we want to connect to SQL, that's another per user license? I do like that the Login screen is not needed (SSO)! I used to work for Microsoft, and I remember we offered a "multi-plexing" licence for Orgs who want to make their Dynamics CRM data accessible to outside users via a portal or something.

Do you think most folks do use SQL for data? A couple articles I found described using SharePoint lists?

Thanks!

John.

[Pstork1 · Accepted solution]

It sounds like you are developing for a public market.  If so Power Apps may not be the right environment for you. Although you can share Power Apps with external users, they do need to have an appropriate license. That can be a license you provide or one they already have through their own environment. But yes, every user will need to have a license and an Azure AD login.  The most common way people get Azure AD logins is through an Office 365 tenant.

I do know of many large multinational organizations that have thousands of users who make use of Power Apps.  But if you are looking to build something to sell it may not be the right environment.  

One correction.  For premium licensing its either per app or per user.  Both will cover connections to SQL.  Per app is cheaper but you pay per app or set of apps. Per user is more expensive, but if you have more than 4 apps its cheaper in the long run.  You can also mix and match.  Per app for a large number of users who only need one or two apps and Per user for everyone else.

There are lots of data sources available. CDS (Dynamics Entity database0, SQL, SharePoint, and even Excel files stored in OneDrive.  Each has strengths and weaknesses, including licensing concerns.

There is a concept you will learn about called delegation.  This simply means the process of offloading record selection to the server. Since Power Apps only lets you retrieve 500-2,000 records at a time delegation becomes critical when working with large data sources.  CDS and SQL have the best delegation support, SharePoint not as good, and Excel has no support for delegation.  On the other hand SharePoint and Excel are included with the Office 365 license, while SQL and CDS require the premium license.  So its a balancing act.  MS tends to be pushing CDS nowadays.  I still like SQL (familiarity), but I usually use SharePoint to alleviate licensing costs.

The point is that the Platform is designed to enhance and extend Dynamics and Office 365 environments.  Its not a generalized development environment like Visual Studio.

[JohnJStraumann]

Shoot, one more clarification. For this note:

"The Per App license, retail $10/user/month, this covers up to two related apps that use premium connectors like SQL or CDS.  This can be less expensive if you only have a few apps that are run by a lot of people in your organization."

From what I have read about the $10 per app license, if a connection to SQL is needed that's an additional fee? In my testing, when I messed with creating a SQL Connection I got a message about needing additional licensing....

[Pstork1 · Accepted solution]

If you are on an Office 365 license you will get the message about needing an additional license when using SQL.  If you are the maker of the app, then in my experience you need a per user license because the per app license is only applied after the app is shared.  So while you are creating the app there is no way to leverage the per app license.  But user's running the app will not need anything additional over the per app license to use SQL.  Its a special case for the maker based on the way the per app license is assigned.