Issue: I am attempting to expose data from a custom entity on the portal, but changes made to any of the custom entity records are not being reflected on the portal.
Portals store the entirety of their data within Dynamics CRM / Dynamics 365, so a caching mechanism is used to ensure that information stored within web templates, web page copy, content snippets, and other records does not have to be retrieved every time a user requests access to it. In a version 8.x or higher portal, this cache is updated only when specific messages are received through Dynamics 365’s change notification infrastructure. Version 7.x portals are handled differently, and this architecture is described in much greater detail in Part Four of this series.
For version 8.x or higher portals, the change notification infrastructure is comprised of a system plugin inside the Dynamics 365 code that listens for all changes happening within the application. If a change occurs on an entity enabled for "Change Tracking", a message is forwarded to an Azure Event Hub for telemetry, reporting, and functionality purposes. By subscribing to these messages, a portal’s cache can be refreshed whenever a change is detected that would impact the portal’s contents.
To reduce the sheer number of notifications being sent to the Azure Event Hub, the "Change Tracking" option is only enabled on out-of-the-box Dynamics 365 and Portal Add-on entities. Any custom entities that have been created within Dynamics 365 are not part of this scope unless the "Change Tracking" option is deliberately enabled on the entity within its customizations page. If this option is unchecked, related messages will not be sent to the Event Hub, and therefore any associated data rendered on the portal will remain stale.
Note that entities that are installed as part of the portal packages (such as Content Snippets) have "Change Tracking" enabled by default, but this value can technically be unchecked/disabled after portal deployment if an administrator chooses to do so. As such, this issue can affect both default and custom entities, but it’s more common with the latter.
Resolution: To fix this, a Dynamics 365 administrator can navigate to Settings -> Customizations -> Customize the System. From the customizations window, the administrator can then click Entities, select the appropriate custom entity, and then enable the "Change Tracking" option toward the bottom of the page by placing a check in the checkbox.
Issue: A "Sorry, but we’re having trouble signing you in. We received a bad request." error along with a "This application requires application permissions to another application." message appears when attempting to sign into the portal using the "Azure AD" external authentication option.
In addition to supporting local user authentication, portals can be configured such that users can sign-in via a variety of external authentication providers. As version 8.x or higher portals are deployed within the Dynamics 365 Administration Center and are associated to the hosting Office 365 tenant, they are designed to support Azure AD authentication by default so that users within that tenant can immediately log into the portal and create a user account using their existing Office 365 credentials. However, to support Azure AD authentication (and server-to-server authentication with Dynamics 365), an App Registration must be created within the Azure subscription associated to that Office 365 tenant with the appropriate permissions granted when the portal is provisioned, otherwise the error highlighted above will occur. Let’s step through the provisioning process to better understand how and why the highlighted error message above occurs.
When a portal’s name, URL, language, and other variables are selected and the "Submit" button is clicked, the user is presented with a Terms of Service screen that requires them to click "Accept". Once this is done, there are a few provisioning steps that begin taking place in the background to successfully complete the deployment process:
While the first two steps take place without any further user action after the deployment is started, the third step requires that the user performing the deployment click "Accept" when prompted with the "Microsoft CRM Portals needs permission to…" message. If this message is ignored or the "Cancel" button is clicked instead, the portal will still be provisioned, but the Azure AD authentication option will not function as the App Registration does not have the proper permissions configured.
Resolution: To fix this, a Global Administrator in the associated Office 365 tenant must sign into the portal using the "Azure AD" external authentication option. At that point, they will once again be prompted with the "Microsoft CRM Portals needs permission to…" message. By clicking "Accept" to this prompt, the App Registration permissions will be configured properly and the error message will no longer appear for other users. Alternatively, a Global Administrator can access the Dynamics 365 Administration Center, navigate to the Applications tab, highlight the portal in question, and click the Manage button. From the Portal Administration Center screen, the "Portal Details" tab can be selected and a "Click here to provide consent to your Dynamics 365 portals." message will appear near the Update button.
Interested in more troubleshooting tips for Dynamics 365 portals? Check out the first installment for an overview of all topics covered throughout this series.
Thanks for this helpful blog.
Does the same change notification infrastructure apply to the Community edition of the portal, i.e. the source code release version? We have deployed the portal in an azure app service but are still having caching issues.
For example, if we add or remove fields to the default Profile Web Form for Contacts when they register on the portal, the changes to the form aren't being reflected.