Power Pages: When to Use (and When Not To)

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.

What is Power Pages?

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.

What Can’t Power Pages Do?

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.

Built on Dataverse

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.

Anonymous Usage

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.

UX Driven Development

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.

Where Does Power Pages Shine?

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.

The post Power Pages: When to Use (and When Not To) appeared first on Engineered Code.