Independent Software Vendors (ISVs) have been an important part of the Microsoft Business Applications space for a long time. ISVs create solutions that build on top of the platforms and products that Microsoft provides off-the-shelf. As the Power Platform has continued to grow and evolve, more opportunities have presented themselves for ISVs. In this post, I’ll look at what ISVs might want to consider when looking at incorporating Power Pages as part of their offering.

At Engineered Code, we’ve worked with a number of ISVs who have chosen to leverage Power Pages as part of their product. Many ISV solutions are built around a common theme: they build out a custom data model, often targeted at a specific vertical, and implement the user interface and business processes around that data model. In most situations for ISVs the value of Power Pages is clear: allow external users to interact with data in that custom model. Even back in my days at Adxstudio (almost 15 years ago!), I worked with ISVs who were including Adxstudio Portals as part of their product.

I wish this was a blog post about how easy it is for ISVs to leverage Power Pages. The truth is right now the Power Platform is built from the point of view of a large organization that is going to use these tools to build internal apps. Power Pages is no exception to that. So, this means that there are a few gotchas that you’re better off knowing about now, as opposed to after you’ve made a big investment.

Let’s get the licensing questions out of the way. There are no specific off-the-shelf licenses for ISVs when it comes to Power Pages that I know of. Back in the day with Adxstudio, they sold an ISV license that allowed you to embedded Portals with your product, so your end client didn’t see the cost. Now your clients will pay the typical price per user (authenticated or anonymous) for Power Pages. Perhaps if you have large enough volume, maybe you can convince Microsoft to give you a discount. But assuming your ISV solution is hosted in their tenant, the cost for Power Pages will show up on their invoices.

Now, let’s talk about the tech used for building out an ISV’s use case on Power Pages. This is where I have good news. You can use Lists and Forms to work with your custom data model. Maybe add a PCF Control to build out a custom UI. Perhaps supplement with a companion app when you need to talk to external data. All of this is relatively straight-forward. In fact, since it is pretty straight-forward, this often leads to ISVs building a pretty quick prototype, before they run into the major problem: distribution.

Moving Power Pages sites between environments has always been a pain in the you-know-what. Lots of solutions exist out there (Portal Records Mover for XrmToolBox, pac CLI, Configuration Migration Tool, solutions with the Enhanced Data Model), but overall, it’s still no easy feat. This gets even more challenging when you have one ISV trying to distribute their site to many customers.

In my conversations with ISVs considering Power Pages as part of their offering, I always have the conversation about whether they feel like their solution comes with a portal or is an add-on to a portal. I usually recommend the latter, for a few reasons. First, if a client already has a Power Pages site, allowing them to add the ISV functionality to it usually means lower licensing and maintenance costs. Secondly, it is challenging to provide a Power Pages site as a product.

Look at Microsoft itself. It provides templates to help you get started. But once you install the template, you don’t get any updates to that template automatically. This is because much of the template exists as data in Dataverse and can be tailored by each client to suit their needs. Going back in later trying to figure out what data you can update is an impossible task at scale. A good example of this would be the look and feel of the site – every organization has different colours, logos, font, etc. So Microsoft basically says you get what you get when you install it, and after that, if you want the new functionality that exists as data in Dataverse, you’re responsible for making those edits manually.

My recommendation is to assume that the client already has a Power Pages site. If they don’t, then obviously that is a great opportunity to provide an additional service to help them get it setup, including branding, authentication, etc. From there, provide the client with simple to follow instructions on how they add your specific IP. Keep your work as isolated as possible. We like to use web templates with a naming convention for any custom HTML/CSS/Liquid/JavaScript. You can use Liquid include statements to add it wherever the customer needs the functionality, but instruct the client to never touch web templates with that naming convention. This makes future updates easier, as you can change the code in the web templates without fear of losing custom work.

Of course, some ISV solutions might need to be more complex. Perhaps a custom, complex permissions model is needed with table permissions, web roles and web pages. Using the Configuration Migration Tool to import a starter template for a subsection of the site can give you a head start, requiring you only to wire in the correct Website and Parent Page lookups after the data is coped in.

You of course can build out an entire site, and use one of the many techniques mentioned above to copy in the data. I’ve seen this successfully used by ISVs whose customers rely on that ISV for their entire Dataverse environment. In this case that ISV is generally managing that environment for the long term, and it’s easier to keep an eye on what is happening, and how future updates may impact the site.

I also think it’s important to mention Microsoft AppSource. This is the primary marketplace for Microsoft Business Applications. There are different types of listings – you can just list your product without actually delivering via AppSource. But if you’re interested in delivering it via AppSource, this is done via a combination of solutions and configuration data. However, you can’t provision a Power Pages site automatically, so even if you go down that route, there is going to be manual setup after the fact. Perhaps upcoming changes to the admin API (which will allow you to provision a Power Pages site) might fill some of that gap. But as of right now, as an ISV, you probably want to be in AppSource for the visibility, but it doesn’t solve any of the delivery headaches.

At some point in the distant future, I’m hoping Microsoft might open the door to allow third parties to include their own templates to choose from when installing a new site. But there has been no mention of something like that in the release wave plans, so I suspect it would be years away, at least. However, what we have seen recently is the External Apps area in the Set Up workspace, specifically for the new DocuSign integration. While right now there is no way for an ISV to add their own product to the list, I’m hopeful that that day is coming. Again, another reason why I prefer the add-on way of thinking versus a complete site.