ecLearn LMS, developed by Engineered Code, is proud to sponsor Community Summit North America. Visit us at booth #1857 and get on the list for our Summitland Prize!
ecLearn LMS, developed by Engineered Code, is proud to sponsor Community Summit North America. Visit us at booth #1857 and get on the list for our Summitland Prize!
When building a website with Power Pages, there are a few different interfaces that are available. If you’re new to the product, it can be a bit confusing to know what they all are, and what they are used for, especially because there can overlap between them. In this blog post, I’ll do my best to help reduce some of that confusion.
The three interfaces that I’m going to cover are the Power Platform Admin Center, Power Pages Design Studio and the Power Pages Management App. I’ll talk about them in order of oldest to newest.
The Power Pages Management App (PPMA) is a model-driven Power App (MDA) that allows you to control most parts of your Power Pages site. A version of this interface has been around since the beginning – before model-driven Power Apps were even a thing.
It started as a section of the site map in Dynamics CRM. Back then, you couldn’t have multiple apps. When you installed Adxstudio Portals (the name of the product before Microsoft acquired it in 2015), a new section was added to the site map that contains much of what you see today in the Power Pages Management App.
Once MDAs were invented, the Portals Management App was created. Finally, with the introduction of the Enhanced Data Model (EDM), a new version, called the Power Pages Management App, was released. Today, since both the EDM and the Standard Data Model are still supported, you’ll still run into both the Power Pages Management App, and the Portals Management App. However, from a maker’s perspective, they are essentially the same thing, and serve the same purpose.
You can access the PPMA in a few different ways. There are direct links to it in the Power Pages Design Studio, or you can navigate to it like any other MDA via make.powerapps.com or by browsing through the apps when you have any other MDA within that same environment open.
The great thing about the PPMA is that it lets you control the majority of the aspects of your Power Pages site. MDAs are built on top of Dataverse, so any data associated with your Power Pages site that exists in Dataverse can be managed in the PPMA.
There are also certain features where the PPMA is the only one of the three standard interfaces that can be used to configure them.
For example:
Aside from those “exclusive” features, the PPMA can be used to create and manage content like Web Pages, Web Templates, Web Files and Content Snippets.
However, despite all these great features, Microsoft has been hard at work building new interfaces to reduce the need to use the PPMA.
The great part about the MDA technology is that it makes it easy and quick to build applications. However, the resulting user experience isn’t always ideal. Let’s look at Table Permissions, for example. For years, the only way to manage table permissions was in the PPMA. It was functional – you could accomplish everything you needed to do. However, it wasn’t the most intuitive interface. It wasn’t always easy to visualize how you had setup your permissions structure. And it probably took more clicks that many would like. Later in this post, we’ll look at what Microsoft has done to improve the experience of creating Table Permissions.
The PPMA is an extremely useful tool, but there is a bit of a learning curve, and the user experience isn’t always ideal. However, if you’re serious about building with Power Pages, you’ll need to be comfortable diving into it to build anything other than the most basic of sites.
When Microsoft acquired Adxstudio, they turned the product into an exclusively Software-as-a-Service (SaaS) offering. Prior to this, most Adxstudio Portals sites were hosted on servers managed by customers or partners. Because of this, any server-level configuration could be done directly on the servers managed by those people. Once the SaaS offering came about, Microsoft needed to provide administrators a way to perform certain operations that impacted the Power Pages server, such as SharePoint and Power BI integration, or custom domains and SSL certificates.
The first iteration of this interface was known as the Portals Admin Center. It was a separate administrative experience exclusive to Power Pages. However, a few years ago, Microsoft moved away from product-specific admin experiences, and towards consolidation into the Power Platform Admin Center.
The Power Platform Admin Center (PPAC), which is available at https://admin.powerplatform.microsoft.com/, has an area dedicated to Power Pages sites. The key difference here is that, for the most part, changes done in the Power Platform Admin Center aren’t impacting data in Dataverse – instead changes impact settings on the server hosting your Power Pages site. This includes settings like:
You’ll also find the Site Checker tool in the PPAC. This is also where you can upgrade the Dataverse solutions associated with Power Pages.
For the most part, when building a Power Pages site, you won’t be in the PPAC on a daily basis – instead, it is generally used for setting things up that only need to be done once per site. However, it is an interface that every Power Pages maker should be familiar with.
The first version of the Power Pages Design Studio (PPDS) was introduced as part of the renaming from Dynamics 365 Portals to Power Apps Portals.
You can access the PPDS by going to https://make.powerpages.microsoft.com/. Then click the edit button for your specific site, since there may be multiple in a single environment.
There are some things that can only be done via the PPDS. This includes:
However, much of what people do in the PPDS can be done in the PPMA. But, while in the PPMA the user experience is somewhat limited to what the MDA framework allows, there are no such limitations in the PPDS, as this is essentially a custom web application built by the Power Pages product team. This means they can build an optimized experience tailors to the needs of those building with Power Pages, especially low/no-code makers and people new to the product.
Let’s look at Table Permissions again. In the Security Workspace, the Table Permissions area is a much more intuitive experience for someone new to Power Pages. Creating child permissions is easier, and being able to see at a glance what you permissions model looks like is very helpful.
Another example of this are the Advanced settings in the Security Workspace. This is just an enhanced editor for certain Site Settings. These Site Settings can be managed in the PPMA, however in the PPMA, there is no explanation as to what the settings are for, and no validation to ensure that the value for the settings provided is even in the correct format.
The page editor experience is another thing that makers may prefer over what is available in the PPMA. You can build a page layout using blocks of content and a drag-and-drop interface. Could you build the same HTML yourself in the PPMA? Yes. However, the PPDS is targeted at those new to the platform, not experienced web developers.
One feature in the PPDS that bridges the gap between low/no-code and pro-code is the Edit code button that appears within the Pages Workspace. This opens up VS Code for Web, which allows the user to edit HTML, CSS and JavaScript in a more developer-friendly interface.
Microsoft continues to invest heavily in the PPDS. Recently, enhancements have been made to allow users to manage certain Form Metadata right in the PPDS (although certain other types of Form Metadata still require the PPMA).
While I do think this trend will continue, I’m not sure I ever see the PPMA ever going completely away. I think there will always be a few less-used features where it won’t make sense to build into the PPDS, but Microsoft won’t be able to remove them, so instead they’ll continue to support the PPMA long term.
While I like the idea of simpler interfaces to do things, my concern has also been about the balance between making existing features easier to use, versus adding new features that don’t exist yet. As someone who has used the product for over 15 years, the interfaces don’t present a challenge, so I lean towards having new features. But of course, if we have more and more people using the product, that will lead to a big and better product team that can handle both improved interfaces and new features.
Leave a Reply