Intro to Web Pages for Power Apps Portals in Dynamics 365

Dynamics 365 Portal serves up web pages that provide a sort of doorway or entrance into your Dynamics 365 CRM environment.

Without Portal, only licensed users can access your CRM, whether they have a full Dynamics 365 Sales license or a simple Team license. Dynamics 365 Portal opens access to non-licensed D365 users – they get to jump through the portal and explore, add, edit, delete, and view D365 CRM data as determined by the Portal developer.

In this blog, I will cover certain elements of the Web Page – things I feel a beginning D365 Portal developer should know. I will share some ah-has that will hopefully make D365 Web Pages more understandable and easier to develop after gaining this knowledge.

In particular, I will cover the following topics:

• Why Are Portal Web Pages Important?
• Root vs Non-Root, AKA Information Form vs Content Form
• Parent Pages
• Partial URLs
• Web Page Types
• Web Files
• Custom JavaScript and CSS
• Portal Content Editor

Note: Portals in Dynamics 365 Sales are now officially called “Power Pages“. They were previously called “Power Apps Portals”, but are often still referred to as “Dynamics 365 Portals.”

I’m a big sci-fi fan. No, really. I like the imagination, the scientific possibilities, the alternate realities. From Star Trek to Star Wars to Back to the Future to Terminator to Transformers to Heroes to Avengers and on and on. Throughout the sci-fi world, a common theme arises – a portal.

A portal is a doorway, gate, or other entrance. Whether it was Reese trying to save Sarah Connor or Doctor Strange sending someone or something into another dimension, a portal was vital to their success.

D365 Portals allow your non-licensed D365 users to step through and access your CRM.

Why Are Portal Web Pages Important?

The Web Page is the heart of D365 Portals.

Without it, you can build Entity Lists, Entity Forms, and Web Forms. You can configure Web Page Access Control Rules, Web Roles, and Entity Permissions. You can create Content Snippets, Site Markers, and Web Link Sets. You can do all of this and still not have a single web page displaying to the world.

A traditional website architecture would look something like this:

[Free website template provided by HTML5 UP.]

A complex website would have a middle tier like C#, PHP, or Java to communicate back and forth between the frontend website and a backend database, whether it be SQL Server, MySQL, or Oracle. But how does that translate into D365 Portals? Portals take the responsibility of the front and middle while D365 CRM is the database. But as far as Portal development goes, you can do it all inside D365 CRM.

In the end, the Web Page is the center of the universe – it’s the DeLorean sports car time machine of Doc Brown. It’s that important.

Root vs Non-Root, AKA Information Form vs Content Form

There are two sides to a Portal Web Page, and it’s easy to get confused if you don’t know how the two sides work together.

No doubt there contained some serious complexity in first officer Spock – part human, part Vulcan. However the two forces inside functioned as a complete whole and performed admirably. Web Pages also have two forces working together yet maintain a cohesive front to provide your users great web pages.

Using Visual Studio ASP.NET Web Application as an example, a web page is much more than your average web page. On the surface, the ContactUs.aspx file below is a single file that will be displayed on the web:

Drilling down into the file reveals several layers of additional files and supporting components:

D365 Portal Web Pages are similar in the fact that there are multiple layers. When navigating to Web Pages, most likely “Active Web Pages” view will display, revealing only one side of the Web Page. After creating a personal view to include all Web Pages, you would see two pages for every Web Page. Notice the second and third column: “Is Root” and “Root Webpage”.  Herein lies one of the great mysteries of D365 Portal Web Pages.

“I am root.”  “I am root!”  “I AM ROOT!” The root Web Page is emphatic about its identity and has a clear definition in purpose.

When navigating to the Web Page record, you should notice two forms available in the form selector: Information and Content Page:

The Information form represents the root Web Page while the Content Page form represents the non-root Web Page.

Many fields between the two records are similar, but there are some key differences as noted below:

ROOT	NON ROOT (Portal Content Editor)
INFORMATION FORM	CONTENT PAGE FORM
	Webpage
	Webpage Language
Localized Content (has item)	Localized Content (no item)
	Content (Title, Page Copy, and Summary)
Child Pages
Child Files
Access Control Rules
Custom JavaScript	Custom JavaScript
Custom CSS	Custom CSS

What gives? Why is this worth noting? As a beginning Portal developer, you can easily get confused on where to go for certain actions or determining why things happen in certain ways. If you make changes to the Information form (root Web Page) in D365, you may not see those changes on the actual Portal web page and will wonder why.

For example, you need to navigate to the Content Page form (non-root Web Page) Title field in order to change the web page header title, the text that displays at the top of every Portal web page. If you change “Name” on the Information form (root Web Page) record, it will change the page header title, but more chances than not you will want to name your Web Page different in D365 CRM to support a logical and more consistent listing versus how the title is actually displayed on the web.

The Content Page (non-root Web Page) is the Web Page exposed to the Portal Content Editor. We will explore this further in the Portal Content Editor section.

Here is another example. When I added JavaScript to the Portal Content Editor (non-root Web Page), it showed on the Content Page form, not the Information form, and it worked fine in the Portal. When I added JavaScript to the Information form (root Web Page), it didn’t work on the Portal; I commented out the Content Page JavaScript (non-root Web Page) to rule out competing conflicts, and it still didn’t work. Confusing I know, but read through this a couple of times, navigate to the various records, and you’ll begin to see the relationships and responsibilities of the two different sides of the Web Page.

Parent Pages

All but one Web Page needs a parent page. When it comes to website hierarchy, the Home Web Page is like the front door to a building that has no other doors – it’s the only way in and out. If you view the list of Web Pages, you will notice that all Web Pages are associated to a Parent Page except Home. And thinking about a typical website architecture, that makes sense.

Home is at the top, and there is a hierarchical drill-down effect to arrive at General Discussion. You have to go through Forums to get there. Even though Luke Skywalker was confused about his parents, all Web Pages don’t share that same conundrum. In the words of Forums, “General Discussion, I am your father!”

The Parent Page concept directly influences the D365 Portal sitemap and breadcrumb snippet:

When developing your D365 Portal website, consider how users should navigate back and forth. A common scenario is a form page that is the result of selecting a record from a list.

Here is a list of Contacts:

After selecting a Contact record, Portal navigates to the Contact form.

Notice the breadcrumb navigation. Most likely you desire to have your Portal users navigate back to the Contacts list, not Home. The Portal user can either click “Contacts” in the breadcrumb trail navigation or the Back button.

Parent Page is required for all custom Web Pages you create, so carefully plan your website and determine the parent-child hierarchy before starting.

Partial URLs

Partial URLs are pretty straight forward and easy to understand, but it’s worth mentioning that they should be chosen thoughtfully. You enter the Partial URL on the Web Page record, and it is a required field.

This entry directly correlates to the visible URL seen in your browser.

Take a systematic approach when determining partial URLs. What I mean by that is create URLs with the whole website in mind. There may be several Web Pages that deal with Contacts, but partial URLs need to be unique, so what do you do? You could implement something like this:

Entity	Partial URL	Description
Contact	contact_add	Contact form for adding
Contact	contact_edit	Contact form for editing
Contact	contact_view	Contact form for view only

There are definitely some personal preferences that come into play on this topic. Microsoft has chosen to prefix the partial URL with the action being taken.

I follow the entity-action approach for naming my Web Pages, Entity Forms, Web Forms, and Partial URLs. It keeps them all together in lists, and it lets everyone know the most important part first: the entity involved.

Partial URLs are simple but may have a significant negative impact if not thought out properly.

Portal Web Page Types

Each Web Page can be either an Entity List Web Page, Entity Form Web Page, Web Form Web Page, or a custom Web Page. The first two of those already have their own blogs on our site, so I won’t go into much detail. But I want to show a visual of the differences.

Entity List Web Page

The Entity List Web Page lists records of the same type; it is a reproduction of a Dynamics 365 view.

Entity Form Web Page

The Entity Form Web Page displays one record; it is a reproduction of a D365 form.

Web Form Web Page

The Web Form is very similar to the Entity Form but can display multiple steps and multiple record types. For example, step one could contain Contact-entity information, and step two could contain Opportunity-entity information.

Custom Web Page

We have the option of creating a Web Page that neither points to an Entity List, Entity Form, nor a Web Form. So what would actually display on the webpage? Whatever you want, really.

Here I created a Web Page that points to the Blank Page Template. Notice it does not point to an Entity List, Entity Form, or a Web Form.

Display of Web Page:

I can log into the Portal with Portal credentials and edit this page:

Refreshed display of Web Page:

These types of Web Pages are great for non-D365 data pages like Contact Us, About Us, External Resources, etc.

Web Files

Read Microsoft’s explanation of Web Files to have a fuller understanding of this topic, but I want to mention a few things. You can access Web Files from many fronts.

Web Files (Child Files) listed on the Home Web Page inside D365 Customer Engagement:

Web Files (Child Files) listed on the Home Web Page inside Portal Content Editor:

Web Files (Child Files) listed on the Home Web Page inside Portal Content Editor server:

When a Web File is associated to a Web Page, it becomes available for use. On the default Portal homepage, there are several images that are being used; one of them is layer_up.png which aids in the diagonal visual effect on the image:

We can see with the HTML and CSS that it is accessing the image via CSS, and the image is uploaded to the Portal server as indicated in the list of Child Files.

Be careful not to upload the same file all over the website. Once the file is uploaded, it can be accessed from any other web page. If you know the file will be used across many web pages, associate it to the Home Web Page – the root web page.

Let’s say I upload a file which will be used in multiple areas of my D365 Portal. Instead of uploading it multiple times for each Web Page that will use it, I will upload it once to the Home Web Page area.

Text file is a Web File (Child File) of the Home Web Page.

File is uploaded to the Portal server.

By clicking on the properties of the file on the Portal server, I can grab the URL for the file. Next, I can modify an existing Web Page Page Copy and reference the text file.

Refreshed view of Web Page:

Clicking on the link will download the file:

And place it in the Downloads folder:

File:

If you are more advanced and would like to upload a JavaScript file, be sure to read Colin Vermander’s article.

You have many options concerning Web Files of which you can access via HTML, JavaScript, and CSS.

Custom JavaScript and CSS for Portal Web Pages

Microsoft recommends using JQuery only for HTML Web Resources, not form scripts or ribbon commands inside D365 CE. However JQuery is fully supported in D365 Portals. Yeah!

By default, D365 Portals comes with a JQuery JS file; you can find the reference by viewing the source code down at the bottom of the HTML:

What does this mean for you, the Portal developer? It means you can tap into the power of JQuery to supplement out-of-the-box functionality.

For simplicity’s sake, let’s say you have a custom Web Page and would like to add some dynamic JQuery functionality. You want to display a message to your users but desire it to fade after a short time. Log into D365 Portal with your administrative credentials. Navigate to the desired page and click Edit; navigate to the Language Content tab and add your desired message.

Then navigate to the the Options tab and add the JQuery:

Now when the page loads, your message will display – for this example – for 10 seconds:

Then the message will fade out nicely:

A word of warning for adding custom CSS – much like the use of Web Files: use the philosophy of “Write once – use many times.” Personally, I wouldn’t recommend using the CSS section for an individual Web Page. Only if determined by stakeholders that it is a unique instance would I pursue this route. The better approach is to add to the theme.css CSS file as mentioned in D365 Portal – Other – Part 1 – CSS. For illustration purposes, let’s see how this could work.

I feel the table column headers for out-of-the-box Portal tables are pretty boring. Let’s dress them up a bit.

Right click any one of the column header links and select Inspect. View and understand the HTML elements and CSS involved.

Edit the page in the Portal Content Editor, navigate to Options tab, add the following CSS, and click Save.

Refresh the page and see the results:

Portal Content Editor

The Portal Content Editor is a very helpful tool for D365 Portal. Understanding it will make you faster and better at certain tasks.

My son just finished long division in school. He asked the same question as millions of other children, “why?” The answer is simply that you need to understand long division, how to estimate, how to multiply, subtract, borrow, and determine the remainder. In a few short weeks, he will be allowed to use a calculator in school, and long division will change from a half-a-page per problem to a few seconds on the calculator and a one-line answer. If you only know the calculator side, it wouldn’t do you much good if a problem arises. You wouldn’t have the math ability to determine the nature of the problem and how to fix it.

The same goes for the D365 Portal Web Page: You need to understand how it works and how it’s put together before fully understanding and appreciating the Portal Content Editor.

In the Root vs Non-Root section above, I emphasized that the Portal Content Editor displayed the non-root Web Page. This is true, but it also surfaces two elements of the root Web Page.

Logged in as the Portal administrator and clicking New reveals the ability to manage Child Pages and Child Files. With the Portal Content Editor and the knowledge of everything above, you can create and manage many of the components that make up the entirety of a D365 Portal website.

You might be wondering, even still, where to go to accomplish any given task. The table below demonstrates my usage of the three different tools:

D365 CE	D365 Portal Content Editor	Portal Server
Creation of Web Pages	Custom JavaScript	Managing Child Files
Access Control Rules	Managing page header title
	Managing Page Copy
	At times – reassignment of Entity List or Entity Form

The Portal Content Editor is a great tool and can make certain tasks easier and faster.  Try developing with all the available tools and see which mix is best for you.

Summary

Throughout this blog, I have attempted to provide key information to aid in your Portal development and hopefully prevent some common errors and pitfalls. We traveled over the vital importance of the Web Page and that it is two dimensional in nature. Web Pages have parent Web Pages, and we have the authority to create our own URLs. Web Files are critical in filling out a robust Portal and can support your custom JavaScript and CSS. Finally the Portal Content Editor is your developing friend.

Please also explore our related articles:

• Portal Web Page Templates
• Portal Entity Lists
• Portal Entity Forms
• Portal Licensing

Would your organization benefit from using Portals in Dynamics 365? Connect with us to discuss any time.