Engineered Code is proud to announce the availability of ecLearn - the Learning Management System built on top of Microsoft Dataverse

ENGINEERED CODE BLOG

Power Pages: Versus Power Apps

A question I recently saw on the Power Platform Community forums asked why would someone use Power Apps (I’m assuming they are referring to canvas apps) instead of Power Pages. They mentioned that using Dataverse with Power Apps requires a premium license, so I think the implication is that Power Pages might be a cheaper option. In this blog post, I’m going to look at some of considerations when making the choice between Power Pages and Power Apps (both model-driven and canvas).

Internal vs External

One thing that usually makes the decision pretty easy is whether the users of your application are internal to the organization, or external.

Power Pages sites support either scenario. In addition to Microsoft Entra ID, you can use any authentication providers that support protocols like Open ID Connect (like Entra External ID and Azure AD B2C), SAML 2.0, and WS-Federation, plus a number of built-in OAuth 2.0 providers.

Power Apps (either canvas or model-driven) require authentication using Microsoft Entra ID. While it is possible to enable guest user access to Power Apps, I think it is fair to say that in most cases, if your users are external, and you aren’t already managing them as guests in your Entra ID tenant, that Power Pages is probably going to be the best fit.

Where’s the Data?

The original question talked about Dataverse as the data source. If that is the case in your situation, then all the options are on the table. Power Pages and model-driven Power Apps require the use of Dataverse. While not required, Dataverse is a great option for canvas-based Power Apps.

However, if you’re not already planning on using Dataverse, canvas-based Power Apps provide a whole lot of connectors that allow you to access other data sources, both Microsoft and third-party.

While it is true that you can connect model-driven Power Apps and Power Pages to other data sources via virtual tables or other integration techniques, I would say it introduces another layer of complexity. So still an option, but I think there is a good reason that when dealing with other data sources, canvas-based Power Apps are many people’s go-to option.

User Interface

I think the biggest difference between the three options is the interface for your users, and how much time it takes to build that interface.

Now, before I get too many comments, what follows are certainly generalizations. With custom code or PCF controls, you can pretty much do anything with any of these three options. So for the purposes of this post, I’m going to consider scenarios where we want to limit the amount of custom code that is required.

Canvas apps provide great flexibility, allowing you to design basically from scratch. But developing from scratch takes time.

Model-driven apps provide a relatively rigid framework. Less flexible, but you can do things pretty quickly. In terms of the end result, the MDA interface is more complex (and includes many more features out of the box). In our experience, training is often required for users new to MDAs.

I think Power Pages lives somewhere in between. While not as flexible as canvas apps, the resulting experience is typically simpler than that of a model-driven app. The app itself feels much more like a website compared to the other options.

This highlights what we see as the most common use case for Power Pages built for internal users: building an app for people that aren’t frequently users and are not already trained on model-driven apps. An internal help desk is the classic scenario. In these cases, Power Pages is the right balance since it is probably quicker to build a larger, more complex app as compared to canvas apps, but the resulting experience is much simpler compared to model-driven apps.

Native App

Another consideration are native applications. Both types of Power Apps can be accessed via a native app on platforms like iOS and Android.

On the other hand, Power Pages is more of a traditional website, accessed through the browser. Yes, there are progressive web app (PWA) capabilities in Power Pages, but I haven’t found those to be practical in most situations.

So, if your users are expecting a native application installed on their phones or tablets, or if you’re planning on using capabilities like device cameras or location services, Power Apps certainly have the advantage.

Pricing

I don’t really want to turn this post into a licensing discussion, so I’ll just talk about things at a high level.

You can get access to unlimited Power Apps, canvas or model-driven, for $20 USD per user per month. Or you can get a single app for $5 per user per month.

List price for Power Pages, at the lowest volume, is $200 USD for 100 users per month, so $2 per user, per site, per month.

So, if you are looking at a single app, Power Apps is $5 and Power Pages is $2. There are of course more that goes into the decision that just licensing costs, however you can understand the reason for the original poster’s question – Power Pages licensing is cheaper, per user, compared to Power Apps.

Other Factors

Of course, there are lots of other factors that go into choosing between these different platforms. What technologies are the users already familiar with? What technologies are the implementation team already familiar with? Have you already invested in some features (for example, business rules) that can only be used with certain products?

Let me know in the comments what factors you think should be considered when trying to decide between these options.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Contact

Engineered Code is a web application development firm and Microsoft Partner specializing in web portals backed by Dynamics 365 & Power Platform. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.