A new feature of Dynamics 365 is the ability to add a Web Portal for access to the CRM by way of a web front end. This is a modified form of the ADX Studio Portals project bought by Microsoft previously and can be enabled directly in the Office 365 admin portal and configured via the CRM and website (with the correct user role assigned).
It is a great new addition and has huge potential as a useful addition to most CRM implementations. In this article I am discussing the issues I had in trying to reflect the changes I made in the CRM to the portal front end, the only way I seemed to be able to get the changes to “Publish” were by turning the Web Application off and then on again. This is not a good workflow for any sane development/customisation.
In trying to find more details I stumbled across the answer from Patrick Dykema on the Dynamics CRM Forums (https://community.dynamics.com/crm/f/117/p/210500/599644). This article is based on the steps he outlines with a little more detail, so thanks go to Patrick for this!
Update 18/02/2017 – This article is still relevant, though it is not recommended by Microsoft any longer. The new process to update changes is actually by enabling Change Tracking on the relevant entity as noted in this support blog article – Portal Troubleshooting, Part One: Stale Data and Bad Requests.
Quick Fix Steps
- Open the CRM solution called Web Notification (Settings > Solutions).
- Create a Web Notification URL record if required. This should have the URL of your portal (https://portalname.microsoftcrmportals.com for Microsoft hosted) with the path /WebNotification.axd added; for example https://portalname.microsoftcrmportals.com/WebNotification.axd.
- Return to the Web Notification Solution and refresh the page to see the Notification Configuration page.
- Select any entity you want to force a refresh, during Portal development it is easiest to select any entity that is related to ADX/Portals functionality; basically anything beginning Web and the Entity List and Entity Form.
- Removal of these notifications can be actioned by performing these same steps in reverse.
The process that will be outlined here is enabling plugins in the CRM to use a Web Notification mechanism to communicate with the hosted website forcing it to invalidate the stored data in the cache and therefore the next time you load the portal page the latest changes are requested from the CRM rather than the cache. There is an article on the ADX Studios Support site that covers this but the URL seems to be different to the one used and I think it is because the documentation is out of date (https://community.adxstudio.com/products/adxstudio-portals/documentation/developers-guide/cache/web-notifications/).
There is an inherent cost in performance to enabling this as the plugin will fire for all operations on all entities selected in this process. Exactly how much of a cost is not clear but it is worth mentioning and noting that only entities that need to provide the latest data in the portal and are likely to change in the CRM regularly too. For the purposes of this article we will enable relevant ADX entities to update the portal as we make changes.
To begin we need to open the Web Notification solution in the CRM, this is added by default when installing a CRM Portal.
As above it is likely you will not already have a Web Notification URL record in the system so follow the link to add a new record. This is simply a new entity record so create a new record as normal.
The Name can be anything but the URL must be the default URL of the portal with the path /WebNotification.axd added to the end. An example URL would be: https://myportalname.com/WebNotification.axd.
Once a new Web Notification URL record is created you should be able to open the Web Notification solution again and see the configuration screen below to continue.
This shows the notifications already set but basically you select the entities on the left you need and then adding them to the right with the arrow. After you have added the Send Notifications needed clicking Save and Publish will register the plugin steps on the required entities and next time you change one of these entities the plugin will trigger and you will see your changes in the portal.
Happy Portal Publishing!
This does not mean that your changes to web pages made in the CRM will instantly reflect in the front end portal, the plugin is an asynchronous plugin and therefore can take a few seconds (or minutes) to kick in. You can see this working if you enable Plugin Tracing via the Customization tab of the System Settings then looking at the trace logs under Settings.