ReadyXRM

When you deploy a PowerApps Portal on your CDS environment, you will notice that a model-driven app called “Portal Management” is also created as part of the provisioning process. This app also appeared when you provisioned a Dynamics 365 Portal.

With the new Portal maker experience, you can create web pages, entity lists, entity forms and basic static content. However, to fine tune many aspects of the portal (including adding advanced features like web forms and creating web templates) you will need to use the Portal Management App.

The Portal Management App effectively allows an admin or maker to navigate the portal metadata entities.

The purpose of this post is to give a high level overview of the app and the specific portal metadata entities and what they are used for. Hopefully this knowledge will help new PowerApps Portals makers some helpful context as they build new apps.

You will be able to navigate to the app from either https://make.powerapps.com or https://home.dynamics.com

Web Site Section

The Web Site section contains the entities used to manage the overall behavior of the portal(s) installed on the specific CDS instance.

Web Sites

The web site record is the main container for a specific portal instance. You will be able to specify headers, footers and languages. This record will parent most of the specific portal metadata entity types. You are able to have multiple portals (web site records), however, for CDS only based PowerApps Portals there is currently no easy mechanism for creating multiple sites.

Even if you create a website record, you would have to create all the related metadata entities and settings, which is pretty much impossible and not at all recommended.

Page Templates

If you create a new Liquid web page template (see below), you will need a corresponding Page Template in order for it to appear in the portal maker studio to use with a web page. This is based on legacy structure where a page template may “point” to an aspx page or a web template to be used as a foundation for a web page.

Redirect

A redirect record is meant to be a temporary “detour” for specific pages or sections going under maintenance. If a particular URL is intercepted as specified in the redirect record, it can be redirected to external URL, a web page or a site marker.

Site Marker

A site marker is effectively a short cut to a specific web page. This allows web template developers to not to have to hard code specific links, so admin or even a content provider can “move” web pages to different levels in the heirarchy of a portal.

Site Settings

Site Settings are effectively the “registry” settings of a portal. This is where many specific aspects of a portal are configured, such as authentication, sign-in settings, and many more. Microsoft has promised at some point to publish a full list of all possible site settings. Some are indicated on docs.microsoft.com, some are blogs, many are unpublished. Check Nick Hayduk’s various blogs as he tends to uncover many of these settings.

Web Site Bindings

Web Site Bindings effectly are used to specify and configure the unique URL for the portal.

Settings

While Site Settings are specific to a portal, the settings records generally relate to the entire portal solution setup. There usually are not many portals settings records.

Content Section

The contect section lists the entities that store the actual content that is displayed on a PowerApps Portal. The portal maker studio will be able to create and configure portal data that will appear here. However, you may need to navigate these records to update specific aspects.

Content Snippets

Content Snippets are reusable content pieces that can be referenced in many places on the portal (consider headers and footers). They only need to be updated once and will be automatically reflected on the entire portal. Content snippets can contain text, Liquid, HTML, CSS and other types of content.

Entity Forms

Entity forms are a core component of a Portal as they are take an existing model driven form and will surface it to a portal page. Entity forms are somewhat configurable from the portal maker studio but can be further defined in the Portal Management App. An entity form allows read-only, edit and create forms.

Entity Form Metadata

Entity form metadata allows portal admin to further configure entity forms such as predefining values and configuring embedded views.

Entity Lists

While entity forms surface a model-driven form, the entity lists are used to configure a model-driven view configuration to a portal page. Again, the new portal maker studio allows for a fair amount of configuration but fine tuning and working around some “preview” issues requires the Portal Management App.

Shortcuts

A Shortcut record allows a portal maker to make a direct link on a web page to another web page, web file or even an external URL, regardless of the hierarchy/site map of the portal. Be default, the short cut link will appear as a link on the parent web page along with the list of other child pages. In most cases, you would likely use a Site Maker instead as these provide more flexibility and can be dropped anywhere, where a shortcut is linked to specific parent page.

Web Files

Web file records are used to store actually “files” as part of the notes functionality. These files can be anything from actually downloadable files to referencing actual portal CSS, JavaScript and graphical image files.

Web Forms

Web forms are a component that are similiar to entity forms but create a sequence of steps that can be used to build a portal based business process flow. The Web form is container for a collection of Web Form Step records that define what the user needs to input or branching decisions or redirects. Web Forms can be further configured using Web Form Metadata. Web Forms can be very complicated and setting them up in a model driven app becomes very cumbersome. I hope that someday someone (Jim?) will create an XrmToolBox tool (or a Canvas App) to easily configure web forms.

Web Link Sets/Web Links

Web Links represent the menu items you see along the top or the side of a web page on the portal. These can point to specific web pages or to external URLs. The web links are collected and grouped as Web Link Sets, which persist across a web site or can be reused on specific web pages. If a logged in user does not have access to a specific page, the default setting is that they also will not see the corresponding web link (this can be shut off).

Portal Languages

The portal language records will have been pre-populated during provisioning and unless you have a specific reason to change the codes/ids of languages then these should be left alone. You will need to add the additional language via the website record and also ensure that it is configured your CDS environment.

Web Pages

The web page record is the core of the portal in that it defines the actual displayed content, both static and via other components like entity lists and entity forms. A web page can be created and edited using the portal maker studio and generally you will not need to modify it via the Portal Management App. Note that for each web page on the portal there is always a minimum of two records, one “root” page and one page specific to the language of the portal to contain the actual content. Note at the time of this post, the autosave will create pages named “new-page(x)” and the root page will not update if you edit the name using the portal maker studio.

Web Templates

The Web Template record contains the Liquid, HTML, CSS or JavaScript code that make up the foundation of a web page. There are a set of predefined web templates which would allow a new user to create a basic portal without needing to dive deep into the code. However, once someone gets more comfortable there will be a need to further tweak and define the portal. Much of this work will (or should) exist in a web template. Web templates can reference other web templates, allowing a structure and reuse to occur. A Web template will also need a corresponding page template in order to be used as the basis of a web page.

Security Section

PowerApps Portals have their own security context and do not extend existing CDS security. The main concept is that a portal user is represented by a Contact record and can authenticate and login into a portal. This currently needs to be managed completely from within the Portal Management App.

Contacts

The contact entity is the actual CDS contact entity as all authenticated users must have a corresponding contact record (despite authentication method). Depending on your registration method, portal visitors may be able to create and edit their own contact records.

Entity Permissions

The entity permission records define the scope and permissions that a particular logged in user has to specific model driven CDS data. This ensures that specific information in CDS is available to the correct users (contacts)

Invitations

An invitation record is linked to an existing CDS based contact and will allow them to set thier own password and details but linked to an existing contact, without the need to create a duplicate contact.

Publishing State Transition Rules

External users can be given the ability to create and update portal content, however there may be further rules in place to allow for an approval process. The publishing state transition rule records define who can either publish or unpublish content on the portal.

Web Page Access Control Rules

Web page access control rules link a specific web page to a web role (see below) which is linked to portal users. This controls what static content (pages) a user can see or not see. This doesn’t necessary protect your CDS data, which is better protected using entity permissions.

Web Roles

The web role record is essentially the portal “security role” that can be assigned to a portal user. The web role is linked to either entity permissions or web page access control rules and is used to control access to content and data.

Website Access Permissions

Website access permissions define what high level “web site” editing permissions specific administrative roles have of the portal. These are created during the portal provisioning process and generally do not need to be tweaked unless there is a specific reason.

Publishing States

The portal is configured with two publishing states (published and draft) that indicated if a specific portal component is visible on a portal or only visible to content editors or administrators.

Summary

If you are playing around with PowerApps Portals preview, you really should get familiar with the Portal Management App. Understanding the portal metadata is critical to building powerfull PowerApps Portals. You may not need to make adjustments to all specific portal metadata records but understanding them would go a long way.

Cover Photo by yinka adeoti on Unsplash

Nick Doelman is a Microsoft Business Applications MVP, Trainer, Blogger and Speaker. Keep up with PowerApps Portals and Power Platform news at https://twitter.com/readyxrm