ReadyXRM

If you have been paying attention to the Microsoft Power Platform release plans, watched sessions at Ignite as well as read Microsoft’s official Power Platform blog, you will have seen a whole series of new Power Apps portals features either released to general availability or preview in the past few months.

Side note: Trading in the MVP badge for the blue badge

Before I dive into these new features, you may have noticed a few things regarding this blog or some updates on my LinkedIn profile. As of the end of September, I am now a full-time employee of the Microsoft Corporation. My role is Senior Content Developer focused on the Power Apps portals documentation (along with a few other projects). I wasn’t looking for a new role but it was a great opportunity that popped up and allows me to continue to work with Power Platform technologies and work much more closely with the Power Apps portals team than I did as an MVP. One of the criteria of the MVP program is that MVPs cannot be employees of Microsoft. So after 5 years, I am no longer a Microsoft MVP. However, I still hope to be involved in the community and I hope to continue providing my insights on this blog and look for the Refresh the Cache podcast to start producing new episodes.

One of the great perks of my new job is that I get a first-hand look at the new features as they are released. Let’s take a look at some of the new features hitting public preview or general availability.

Power Apps portals new feature: Multiple Portals

In early 2019 I wrote a post outlining how to create a multi-branded portal. This was to address situations where you might need a uniquely branded portal for completely different audiences yet still have them linked to one Microsoft Dataverse. The strategy required a mix of Liquid and CSS and had some limitations such as a common login page and a common URL with sub-pages for each unique “portal”.

Fast forward to 2021 and you can now add up to 50 unique portals to a single Dataverse environment! Each portal can be configured with its own URL, branding, table permissions, etc. This will create a separate website and associated records. Another handy feature is that you could create a new portal using existing portal metadata (that is currently not linked to an active portal). This means if you created a trial or proof of concept portal, and the portal trial expired, you can re-provision a new portal using that portal metadata.

A single contact would use the same authentication method (login/password) to access each unique portal, (which means you provide access to one portal, they will have access to all portals) but you can assign them unique web roles based on the portal they are visiting.

More information can be found here.

Power Apps portals new feature: portal web API read

The Power Apps portals web API is a gamechanger when extending or customizing Power Apps portals. Prior to the web API being available, you could only create or update Dataverse records using basic or advanced form submits, or creating a companion app or other questionable workarounds. The portal web API originally only had create, update, delete and associate action endpoints. What about the ability to read data? For most cases, you could use Liquid to fetch any Dataverse data that you needed to work with. While this worked for many cases (and you could also create your own data-retrieval api to get data) there are cases where you might want to retrieve a value from Dataverse as part of a process on a portal page (e.g. getting a tax rate based on the province/state value entered by a user). Now the portals web API supports the *get* action and now provides full “CRUD” capabilities (create-read-update-delete).

Note: Looking to generate portal web API code (or other Dataverse API code?) then check out Guido Preite’s Dataverse Rest Builder! The tool is amazing and allows you to easily generate code (for lazy developers like me).

webapi.safeAjax({
	type: "GET",
	url: "/_api/avngr_classes(288631e3-68ff-e911-a811-000d3af43355)?$select=avngr_classname,avngr_confirmedregistrations,avngr_startdateandtime",
	contentType: "application/json",
	success: function (data, textStatus, xhr) {
		var result = data;
		console.log(result);
		// Columns
		var avngr_classid = result["avngr_classid"]; // Guid
		var avngr_classname = result["avngr_classname"]; // Text
		var avngr_confirmedregistrations = result["avngr_confirmedregistrations"]; // Whole Number
		var avngr_startdateandtime = result["avngr_startdateandtime"]; // Date Time
	}
});

Power Apps portals new feature: Add code components using Liquid

Another game-changer in extending Power Apps portals is the ability to add code components (formally known as PCF controls). The ability to add code components isn’t new to portals as you could add them to form fields via metadata configuration. However, this new ability allows you to add a code component via a Liquid tag, which means you can add a code component just about anywhere in portals where you can apply Liquid. The other amazing feature is that you write code components to use the full portal web API, so instead of being stuck with things like the standard basic or advanced forms to interact with Dataverse data, you could create your own custom control to pretty much do what you want. You can find a sample here but I am eager to see what other solutions the community can come up with.

Power Apps portals new feature: Deployment profiles of portals using Power Platform CLI

I will admit that I still use the XrmToolBox Portals Code Editor for my primary web template editing and the Portals Records Mover to move the portal’s metadata between environments. However, there have been great advances in using the Power Platform CLI to download and upload portal metadata to a local repository and edit it using tools like VS Code. The Power Platform CLI is now out of preview and considered Generally Available, meaning it is fully supported. You can now either use the command line or even scripts to download or update portal metadata and move to source control or across environments. A very cool new feature is deployment profiles. Have you ever created a developer portal and made sure the home page title said “DEV”? And then when you move your portal metadata to a new environment, you need to remember to update the corresponding snippet or code to reflect “TEST” or “PROD”? (This and other examples of minor differences between environments.) Using deployment profiles, you can specify custom content for each destination environment as you upload portal metadata.

Power Apps portals new feature: Pay-as-you-go for internal users

While the primary use of Power Apps portals is to provide external users with a way to interact with Dataverse data, there are use cases where a portal can be created for internal users. Consider a portal that provides the ability for employees to make vacation requests or internally order new equipment. The licensing requires each of these users to at minimum have a Power Apps per-app pass license. Since that is a monthly cost if it’s a portal that only a handful of employees use on a monthly basis it can become incredibly expensive. With the pay-as-you-go model, the user will only consume a license when they access the portal, and that will come out of monthly Azure credits.

So if a user only needs to use a portal once a year, the company will only be charged the appropriate Azure credits for that usage vs a monthly fee whether they use it or not. Think of your cable TV bill (you pay monthly whether you watch TV or not) vs your electric bill (you pay for what you use). Note that the pay-as-you-go charge is more ($10) than the monthly per-app pass charge ($5) so you may need to plan accordingly.

Summary

These are just a few of the new features that are now in public preview or generally available for Power Apps portals. There is more on the horizon and I hopefully can provide some more context beyond the official documentation as these new features arrive.

Cover Photo by Nick Fewings on Unsplash

Pay-as-you-go Photo by Ross Sneddon on Unsplash

Nick Doelman is a Senior Content Developer for Microsoft, however, the views, opinions expressed in this post are of his own and not of the Microsoft Corporation.