In a previous blog post I had mentioned how it can be useful to use the Portals Source Code release to actually step through Portal source code in a debugger. However, there are more great uses for the Portals source code, even if you are using the official Microsoft-hosted option.

A Quick Introduction to the Portals Source Code

In the summer of 2017 Microsoft made available the entire source code of v8.3 of Dynamics 365 Portals. By doing this, Microsoft provided an option for Dynamics 365 on-premise customers (for whom the official Dynamics 365 Portals is not available), as well as provided a very useful tool in the process of upgrading from v7 to v8 (see my MSDynamicsWorld article on the upgrade process for more info).

This release is provided as-is by Microsoft, completely unsupported, and there are no plans to release the source code for future versions.

Adoxio (the firm spun off of Adxstudio, who originally built the Portals, and who has since been acquired by KPMG) took the source code and uploaded it to GitHub, using the name xRM Portals Community Edition. We strongly recommend that if you need to use the source code, to use this version, as there is a community effort to keep this version viable.

Debugging Errors using Portals Server-side Code

For the sake of completeness, I’ll mention it here again – for the time being you can download the source code, point it at your Dynamics 365 instance, and get your Portal running on a local development web server. See my previous blog post for the three simple steps to get started.

The same old disclaimer applies – this will only work for so long. The Portals Source Code Release was based on v8.3; currently the latest version is v8.4.1. There haven’t been any huge changes, but there have been some minor ones. If you notice some inconsistencies between using the source code release and the real Microsoft version, it might be because something has changed. As new versions come out, the chances of that will only increase. That being said, much of the core functionality hasn’t changed, so this is still a great technique.

Discovering Hidden Site Settings

While the documentation is getting better, there are still a lot of areas that are undocumented. This is especially true for Site Settings.

Site Settings are essentially key-value pairs used to configure various aspects of the system, including authentication, search, output caching and much more. But you won’t find a reference to all of the possibilities in the documentation. A great example would be a site setting called blogs/displaySearch. While this Site Setting is created by default when you provision a new Portal, I don’t see it referenced anywhere in the Portal documentation. If you at some point turned it off by deleting the record (which you shouldn’t do, instead of just setting it to false), you may forget the exact naming convention. A quick look in the code makes it easy to get that functionality back.

Discovering Hidden Content Snippets

Similar to Site Settings, Content Snippets are key-value pairs that are used throughout a Portal for displaying text or HTML. For example, Content Snippets are used to control the labels that appear in the Ideas functionality. If you create a snippet with the name Idea Search Title, you can change the text that appears in the breadcrumbs on the Idea search page (it defaults to “Search Ideas”). This would be helpful if you wanted to leverage the Ideas functionality, but for some reason wanted to give it a different name.

While you may be able to refer to some of the legacy Adxstudio v7 documentation, obviously it doesn’t apply to new functionality. By looking in the source code, you can identify where the text is coming from.

Understanding the Out-of-the-box Functionality

I recently responded to a Dynamics 365 Community Forum thread about making workflow-generated notes editable by Portal users, since the out-of-the-box functionality only allows the author of a note to edit it (assuming they have the appropriate permissions). By looking at the source code, I was able to determine that the Portal includes the ID of the contact that created the note in the subject, and uses that to determine if a contact was the author (there is no actual relationship between the note and the contact that created the note via the portal). Therefore, if you included a contact’s ID in the note subject in the exact right way, the Portal would think that the user was the author, and allow them to edit it.

While I may have been able to determine this using trial and error, it was much faster just to take a quick peak in the code to determine how the Portal works. So my recommendation is that if you’re trying to do something a bit outside the box, consider looking through the Portal source code as there is a tonne of valuable information hidden in those lines of code.