Portals in Dynamics 365 | Web Pages 1A

This blog is part of an evolving series on Portals in Dynamics 365, go here to view the Introductory blog with chapters.

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.

Dynamics 365 (D365) Portal serves up web pages that provide a doorway or entrance into your D365 Customer Engagement environment. On its own, only licensed users can access D365 CE, whether it is a full Customer Engagement license or a simple Team license. D365 Portal opens access to non-licensed D365 users – they get to jump through the portal and explore, add, edit, delete, and view D365 CE 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 padawan developer should know. No reason to get pummeled by the Death Star on your first mission. I will share some ah-ha’s 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:

  • Web Page Importance
  • Two Sides to a Web Page
  • Parent Pages
  • Partial URLs
  • Page Templates

Web Page Importance

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. The Web Page is the heart of D365 Portals.

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 takes the responsibility of the front and middle while D365 CE is the database. But as far as Portal development goes, you can do it all inside D365 CE.

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.

The Two Sides to a Web Page

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)
  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 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 CE 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.

Page Templates

Clone Troopers were not always bad. Yea, that’s right. They were created to fight for the Jedi Order, and they created a lot of them. They were templates of Jango Fett and were made from a single mold. If only Order 66 were never issued!

Most web development tools provide a way to create templates, a server-side mechanism to reuse components throughout the entire website. D365 Portals is no different. Even though Page Templates are Part 2 of the Core Basics chapter, we need to understand how the D365 Portal Page Template is constructed.

Page Templates provide the Portal developer the ability to focus on content and not worry about exactly how it will look and feel once it’s displayed on the web. That is determined by the Page Template.

Let’s take a step back and look at the bigger picture:

A Web Page can display an Entity List, Entity Form, or Web Form; it can also display a custom page, but we will cover that in the next blog: Web Pages 1B. This means you can have three different styles of web pages, all using the same Page Template. Good job Jango!

If you think using Dynamics 365 Portals may be useful for your business, please feel free to contact us.

Dynamics 365 CE (CRM) How-To eGuide

41 pages of step-by-step instructions for 6 different key tasks in Dynamics 365 Customer Engagement (CRM). Includes interactions with PowerApps and Flow!

Get the eGuide

Dynamics 365 CE (CRM) How-To eGuide

Get the eGuide