Top 5 Reasons Why Power Pages Might Not Be the Best Option for Your Project

The Power Pages portal is a great way to extend your business processes to a wider audience quickly and straightforwardly. While portals have multiple ways for customization, and you can go far with that, you should always be aware of limitations. Sometimes it can even prevent you from selecting Power Pages as technology for your project. Below you can find several reasons for that.

The web app cache affects the portal configurational records and actual data that should be shared via the application. It can drastically limit your possibilities for data presentation and degrade the user experience. It is a well-known limitation for anyone who worked with portals at least briefly. Most of the Power Pages developers were in a situation where the requirements could not be implemented without awkward multistep processes because you cannot guarantee that data will be available immediately.

Microsoft SLA (Service Level Agreement) states that for Power Pages cache refresh remains 15 minutes. Except for the primary record where the create or update action is triggered, data reflection from Dataverse to websites is never guaranteed to be immediate. So, if you are planning to implement a highly responsive application for your Portal, Power Pages may not be the best option for you.

The current Power Pages` licensing structure is based on volume pricing. And while old page view subscriptions are in effect during the transition period, many companies are currently reconsidering whether the Power Pages are the best solution for their needs.

The modern licensing structure counts :

Considering prices per stock-keeping unit (SKU), it can be expensive to maintain a portal if its audience is wide. Previously Portals with thousands of users but with simplistic use cases could easily fit into the lower tier quota just because of low page load counts per user.

Therefore, before you make a final decision about the technology – consider the audience of your Portal. Sometimes a few dollars saved during development by choosing Power Pages can be consumed by high license costs eventually.

It can hit you hard in multiple ways.

Imagine your Portal failing on every page load with some indistinct null reference error in portal logs. You are trying to get a hold of MS support or investigating sources of old ADX xRM Portals Community Edition to locate a misspelling in the Liquid code or missing lookup in the configurational record.

Another scenario is when the requirement is to modify the behavior of the integral parts of the Power Pages Web Application like sign-in/sign-up flows, attachment downloads, complex integrations like payments, etc. The changes that could be made easily on the custom app can be downright impossible on Power Pages or require weird, sometimes terrible solutions.

Power Pages professionals should also be aware of what website settings are available and how they can alter the behavior of integral parts of the application to locate requirements that are off-limits.

In addition to the complications described in the previous section, you can also be limited in options on how to administer, monitor and optimize the Portal web app itself.

The Portal management admin center has only a basic toolset.

In most cases, load balancers, custom-configured content delivery networks, firewalls, and other custom network solutions are unavailable due to the inability to modify web application behavior or how it is hosted. Microsoft made some improvements to that recently.

Currently, you can enable a content delivery network on your Portal. Azure Front Door powers it and works so that static content (like scripts, images, and style sheets) will be hosted and served from the content delivery network (CDN) server near your location. But only files that are part of a webpage that anonymous users can access are stored in CDN, while authenticated files are always delivered from the application server. Also, restricting website access by IP address on a website is currently not supported using CDN.

The big step for Power Pages is introducing Web Application Firewall (WAF, currently only in preview). WAF is based on Azure Front Door in Prevention mode. In this mode, requests matching the rules defined in the managed rule set are blocked. You can check the list of enforced policies on the Microsoft portal. But it states that WAF can protect against the most common threats like cross-site scripting, local and remote file inclusion, protocol enforcement, etc.

The Power Pages portals provide a comprehensive toolset to enforce security on multiple levels: starting web page access rules to ensure page visibility down to row-level safety via table permissions. The OOB functionality (out-of-the-box functionality) will cover 90% of user scenarios. But it is starting to fall apart when it comes to the more sophisticated use cases like conditional access or complex row-level security setups.

Some of these complex scenarios can be covered via custom liquid templates or by introducing supplementary tables to ensure correct relationships for table permissions. Unfortunately, there are limits to how inventive you can be with all these workarounds, and you should never forget that a more complex security structure poses more risks.

In conclusion, while Power Pages can offer a straightforward and efficient way to extend your business processes to a broader audience, it is essential to be aware of its limitations before selecting it as the technology for your project. The article outlines five reasons you might reconsider using Power Pages: server-side caching, licensing and pricing, the inability to modify the portal application`s core behavior, limited control over the web application, and a complicated security structure. Before making a final decision, it is essential to carefully evaluate your project requirements and weigh the benefits and potential limitations of the tools. Or it is even better to entrust this matter to a reliable partner .