The growth of Power Pages has been an amazing story. Since being acquired by Microsoft in 2015, the product has gone from a niche add-on for Dynamics 365 Customer Engagement to a full-fledged product in the Power Platform. The visibility that comes with getting equal billing to other Power Platform products like Power BI, Power Apps, and Power Automate means that new people are discovering Power Pages all of the time. However, as with any software product, Power Pages isn’t always a fit, even if your project fall under the category of low code web application development platforms. In this post, I will share what I look for when trying to determine if Power Pages is a fit for a given project.
Perhaps you’ve come across this post because someone told you about Power Pages and suggested you look into it for your project. In that case, let’s level set by providing a brief introduction into what Power Pages is.
Power Pages is one of the products in Microsoft’s Power Platform family. It is a no-code/low-code development platform that allows you to build web applications. While it does contain basic content-management capabilities, like the ability to create pages and manage content, it’s primary purpose is to build web application that allows users to interact with business data.
Classic use cases for Power Pages include help desk scenarios where users can create tickets, or partner portals where partner organization can register deals and update customer information.
Technically, there isn’t much that you couldn’t do with Power Pages. It is very extensible; techniques like PCF Controls, custom JavaScript with Web API, and companion apps can be used to accomplish pretty much any business requirement. But just because you can do something with Power Pages doesn’t mean you should.
There is one particular area that is pretty rigid unless you are willing to invest a lot to customize, and that is authentication. Power Pages is designed to work with modern identity providers that support protocols like OpenID Connect and SAML 2.0. There is also a registration and invitation model baked in that you use to get users into your site. If you’re looking for a no or low code solution, understanding how authentication can be setup and leveraging it as it is designed is highly recommended.
Dataverse is a data storage and management technology that acts as the backbone for much of the Power Platform. Think of it as a database on steroids – in addition to being able to store data, it also includes things like a developer API, security model, and the ability to enforce business logic.
Certain Power Platform products use connectors to talk to the underlying services. Connectors are essentially wrappers around APIs that can talk to a variety of technologies, including both Microsoft (like SharePoint and Exchange) and non-Microsoft (like SalesForce, SAP, Amazon). There is of course a connector for Dataverse, so any of the Power Platform services that use connectors can use Dataverse. Power Automate, Power BI and Canvas Power Apps all use connectors.
However, other Power Platform products talk directly to Dataverse, and so they require Dataverse. This includes Model-driven Power Apps, and yes, Power Pages.
So the takeaway here is that Power Pages needs Dataverse. It is a no-code/low-code product for building web applications on top of Dataverse. At a very minimum, the configuration of your Power Pages site is stored in Dataverse. But the product, especially the no/low-code components, has been designed around the idea that the data that you’re interacting with is in Dataverse.
There are of course exceptions to this. You can use features like Virtual Tables to expose external data via Dataverse. Or you can use a variety of integration mechanisms to synchronize your data into Dataverse. Or you can use external APIs (like a companion app) to bring interact with other data via JavaScript on your site. But these are typically not no-code or low-code options. And keep in mind that, as far as I’m concerned, the real “power” of Power Pages is to quickly build web applications on top of Dataverse. If you’re not otherwise using Dataverse, you have to consider whether this is the right product for you.
Historically the licensing model for anonymous users was actually pretty attractive. It was based on page views, and they were relatively low cost. In fact, often I heard about projects who tried to sole use anonymous usage purely because of the cost reasons.
However, with the introduction of the new licensing model for Power Pages, there was a shift to a per-user licensing model for anonymous users. The price is still lower than logged in users, but if you have a site where you expect a lot of users that won’t do a whole lot on the site, it might not be for you. For example, a project where authenticated users upload data that feeds into a search that is available to anonymous users can be quite costly if that search is expected to be used by six or seven figures of users.We are often brought into projects where wireframes, or even more polished designs, have been developed that define the functionality that Power Pages is expected to deliver. In my experience, this often leads to one of two outcomes: stakeholders are disappointed that Power Pages wasn’t able to deliver the exact experience they were expecting, or a significant amount of custom development is done to meet the designs.
Neither of these situations is a win for Power Pages. Most often Power Pages is being pitched as a no-code/low-code platform; if significant custom development is required, the value proposition of Power Pages is almost eliminated. And obviously if expectations are set by designs that aren’t met, no one is happy.
This isn’t to say that you can’t have great user experiences with Power Pages. And certainly some custom development might be needed to achieve that in many cases. However, if those designing the site have no experience with Power Pages, they don’t know how to make use of the no-code/low-code features. Instead they start with a blank canvas and produce a generic design for the web.
We’ve found much greater success when we work with designers that know the platform. When presented with business requirements, there are usually many good ways to accomplish it, and often it can be done with no-code/low-code functionality in Power Pages. However, the chances of a designer who doesn’t know the platform luckily designing something that works with Power Pages are low.
So if the user experience is a high priority, make sure those designing it are familiar with the platform, so that can take advantage of what it offers, instead designing something that just doesn’t fit.
For organizations already using Dataverse, Power Pages is often a great fit. I don’t think there is an easier way to get external audiences to engage with Dataverse data than with Power Pages.
Another consideration is project timelines. Yes, everyone wants their site up as quickly as possible. But if time to market is truly one of the priorities of the project, then Power Pages can get you a site up in weeks, not months or years.
If you don’t want to constantly be worried about maintenance on your site, Power Pages is a great option. Updates to the core site code are done automatically, and updates to Power Pages solutions are relatively rare, and usually have little-to-no impact on the site. We’ve had clients go years between any major maintenance.
For projects with flexibility on how requirements are met, the no-code/low-code features of Power Pages can be a great tool. Organizations are usually pretty firm on what the site needs to do, but there can often be some wiggle room in how it gets done, especially when the advantages of no-code/low-code are presented. A Power Pages site might not always end up the way you first envisioned it, but when you consider all of its advantages, you’ll often find that different doesn’t have to mean worse.
Thank you for this informative article on Power Pages! I have been looking into low-code web application development platforms for my business, and Power Pages seem like a great option to explore further. I appreciate the breakdown of what Power Pages is and what it can and cannot do. The information on authentication and licensing models is particularly helpful in considering whether Power Pages fits my project.
Thanks so much for the kind words!
Nick
For organization where all users have office 365 license and are in Azure AD, Will that license cover power pages or we need separate license.
Power Pages requires separate licensing. There are no Power Pages licenses included in any M365/O365/Azure licenses.
https://powerpages.microsoft.com/en-us/pricing/
Nick
In our power pages project,we would like to give access to external users in our orgs primary Azure AD directory. We plan to add a subset of these external users to a security group and allow only security group users to have the ability to sign into the power pages portal. The home page of course would remain anonymous access. Would like to check if this is possible without using azure b2c.
Hmm. I haven’t done this myself. Maybe Azure AD has something that would allow you to restrict access via the App Registration – does this link help?
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-restrict-your-app-to-a-set-of-users
Otherwise, I could imagine a scenario where you could use Power Automate to only assign a web role to users within security group. Any valid users could login, but only those in the security group would be able to access the protected areas of the site. But you’d have to pay for those users who login but don’t have access – not sure how likely that is to happen.
Nick
I wish I had read this article a few months ago. I am just wrapping up a project that is exactly as you describe, detailed wireframes that were completely ignored, and no explanation on why until the very end when we did UAT with users – who were, as you said, very disappointed.
Some great advice on understanding the product before launching that I am taking to heart. I see now from reviewing your blog and YouTube (obviously I ended up here because of what I am describing), that Power Pages is more Dynamics CRM then Power Apps. Huge difference! That would have been good to know, and probably would have made this a much better experience on both the user and developer side. But at the risk of being negative, Project Managers need to come in and frame expectations in these situations ASAP. If the bridge is no good, no one is happy.
Thanks for the article Nick. Out of interest how does Power Pages work with web analytics tools such as GA4 or Adobe Analytics?
Similarly, how if at all does it work if you have personalisation tools such as Adobe Target?
Power Pages has the “Tracking Code” content snippet that you can use to add web analytics tools. We’ve used GA for many years, as well as Application Insights (in Azure). While I personally don’t have experience with Adobe Analytics, I would be surprised if it didn’t work.
As for Adobe Target, that is not something I’m familiar with, so unfortunately I can’t comment on that.
Nick
Thanks Nick.
What about developing a datalayer to send more granular data to GA/AA?
Yup, we’ve done that before too. It’s all client-side, so no problem with Power Pages.
Nick
That’s great thanks for coming back.
Regards
Thanks for the good info. Considering Power Pages now, and this article helps.
Hi Nick
What a great article!! Thank you. I have been contemplating on starting to use power pages but do not want to tie myself to Microsoft when it comes to deploying the final product.
Is it possible to deploy the end product outside MS’ cloud (e.g. on Amazon, or even local server)?
Thanks again.
No – Power Pages is a software-as-a-service offering where Microsoft does the hosting. I can’t be hosted outside of the Power Platform.
Nick