Webpages are the core of any website, including Power Apps portals. A webpage in a Power Apps portal can display both static and dynamic content and can be configured to follow a site hierarchy. Portal webpages also have a unique structure to allow content to be displayed in different languages.
Each webpage record within a portal has the following attributes:
- Website - The website to which the page belongs. It's a required field that uniquely places the webpage record within a particular portal site.
- Parent page - The parent webpage of the entity in the website content hierarchy. All webpages should have a parent page, except for the single root (Home) page of a website.
- Partial URL - The URL path segment that is used to build the portal URL of the page. The single root (Home) page of your website (the single page that has no associated parent page) must have a partial URL value of a forward slash (/).
That hierarchical structure provides enough information for each webpage to calculate the path that is unique within the website.
|Webpage||Parent page||Partial URL||Calculated path|
|Price List||Partner News||price-list||/news/partners/price-list/|
When a request is received by the Power Apps portals web app, the target Microsoft Dataverse instance and website record are determined based on the domain name. The path part of the request is then used to locate the webpage record with the matching calculated path.
After the webpage has been determined, the page generation process starts with the following high-level steps:
- The Web Page Access Control Rules are checked to determine if the visitor has the permissions to access the page.
- The page template that is linked to the webpage is retrieved to determine the template that will be used to render the page (either an aspx page or web template).
- The template is processed and the page output is built based on:
- Static content that is determined by the portal metadata.
- Dynamic content that is generated by using data from Dataverse or Dynamics 365.
Each webpage represents a specific URL in your site that users can go to. When a user goes to a URL, the content that is associated with that URL is displayed.
Static content is determined by properties of the webpage record, particularly by the Copy field, which usually contains the HTML content of the page. This content can be added or edited in Power Apps portals Studio or added to content webpages.
Generally, a webpage is referenced as a single record. This reference is for convenience; however, multiple webpage entries exist on every page. One root webpage record is part of the site page hierarchy, which is the one you edit when creating a new page. Other components on the page are multiple child records, or content pages, that point to the root entry. These components support multilingual implementations where each child record is responsible for the content in one of the configured languages.
Every webpage, even in a single language portal, will have a root webpage and a content page for the base language. As a result, content for additional languages can be added later.
When a webpage is first created, all properties such as the name, partial URL, template, and so on, are saved in the root record. Content entries are created for each language, and the page properties are copied across. Then, page properties and page content are managed on the content webpage record. Pages in different languages can have different content and a different template, expiration date, navigation, and author, and they can be published on different dates.
You can use the path of the request to locate the webpage record, or the root webpage record, to be exact. The request language is defined either by the request URL, such as
https://www.contoso.com/es-ES/news, or by a browser cookie, and the corresponding content page is located. The content page defines the content and the template but contains no information on how the content is displayed, which is determined by the page template.
Other than the content being defined by the Copy field on the page, a template can also use other properties such as Title, Summary, Display Date, and others. Templates often include the Content Snippets feature as reusable fragments, for example, to render common information such as a copyright message.
Templates can use references to elements of the sitemap such as Web Files, Shortcuts, and Web Links. Because sitemap elements can be secured, they are validated against the Web Page Access Control Rules. For example, if a visitor does not have permissions to access a target page of a shortcut, by default, the shortcut will not be rendered.
Dynamic content is generated by using the following properties:
- Entity Lists - These properties use the view definition of a Power Apps model-driven app to render the list of Dataverse or Dynamics 365 records as part of a webpage, without the need for using custom code. When the view definition changes, so will the page output.
- Entity Forms - Entity Forms place the definition of a Power Apps model-driven app form on a webpage by providing a configuration-only method to render information from Dataverse or Dynamics 365 records. Entity Forms are not limited to displaying information and can be used to create and edit Dataverse records.
- Web Forms - Web Forms are similar to Entity Forms but include some additional functionality. They can render more than one model-driven app form on a website and can work with multiple entities. Web Forms support single or multi-step navigation and conditional branching logic.
- Liquid - Liquid is an open-source template language that is integrated into portals. It can be used by template developers to add dynamic content to pages and to create a variety of custom templates. Liquid allows access to all portal entities, such as a current webpage that is being rendered and its properties or site settings, for example. It can also read Dataverse data by using Entity Lists/Entity Forms or directly by using FetchXML. For more information, see Build queries with FetchXML.
To control access to Dataverse data, portals use the Entity Permissions property. Entity permissions are scoped by using the relationships between a contact and other records. For example, permissions can be applied to the Case entity to restrict authenticated portal users to accessing only their own cases.
Consider the Entity Permissions property as the portal equivalent of Dataverse or Dynamics 365 security roles. Security roles are associated with Basic Users while Entity Permissions apply to portal users (contacts).
Ultimately, the goal for the process of building a webpage is to provide improved security. Any access to portal structures is governed by Web Page Access Control Rules while Entity Permissions help secure access to Dataverse data.
Power Apps portals includes a robust and flexible mechanism for building static pages or the pages that include data from other Dataverse entities. By using a combination of Entity Lists, Entity Forms, Web Forms, and Liquid, you can build complete web applications by extending your Dataverse or Dynamics 365 solutions to external and internal audiences.
For more information, see Manage web pages.