Engineered Code is proud to announce the availability of ecLearn - the Learning Management System built on top of Microsoft Dataverse


Dynamics 365 Portal: Where to Look When Things Are Slow

It seems to be happening more and more these days that we are being asked to assist organizations that have launched a Dynamics 365 Portal but they are unhappy with the performance. If you find yourself dealing with a portal that is slower than you think it should be, this post should give you an idea of where to start looking.

No Magic Button

As with most things in life (especially when it comes to performance), there is no magic button or no silver bullet that will solve all of your problems. Poor performance is often the result of a lot of little things that, on their own, may not be the end of the world, but add them up and they lead to unhappy portal users.

It’s also important that you have realistic expectations. I’ve been working with the Dynamics 365 Portal product for a long time, and I have yet to hear about it winning any awards for being the fastest platform in the world – if you’re looking for sub-second page loads everywhere, this may not be the product for you. That being said, there are many happy customers whose performance is well within acceptable norms, so it definitely is possible.

In the following sections, I’ll outline some of the areas I look at when someone asks me to help with a Portal that isn’t performing to their expectations.

Dynamics 365

This is one is probably the most overlooked issue, even though once you think about it, it is obvious. D365 Portal started as an ISV solution from Adxstudio. Adxstudio didn’t have any special access to Dynamics 365 (or CRM, as it was called back then) data – they had to use the CRM SDK just like everyone else. That is still true to this day – even after the acquisition by Microsoft, they are still using the standard APIs (they are building on the Power Platform just like everyone else!). This means that all of the requests made by the Portal go through the same Dynamics 365 Event Pipeline that you know and love, including the execution of synchronous plugins and workflows. So if you have a slow-running synchronous plugin, your Portal could be affected.

The general rule of thumb is that it will take longer to load/save a form on the Portal then it will take to load/save the same form directly in Dynamics 365. So, if something takes long on a Portal, first check to see if a similar operation also takes long in Dynamics 365. If so, figuring out how speed things up in Dynamics will most likely speed things up in the Portal.

Things to look for:

  • Long running synchronous plugins
  • Long running synchronous workflows
  • Complex queries that may benefit from an index

Complex Entity Permissions

Entity Permissions are a great tool to ensure that Portal users only have access to the data they need to. They are also extremely flexible, due to the Parent-Child capabilities, which in theory allows you to give access to entities many relationships away. However, as they say, with great power comes great responsibility.

Just because you can create an Entity Permission hierarchy 10 levels deep, doesn’t me you should. All of those levels add complexity to the underlying SQL queries that are required to enforce them, which in turn can slow down your performance.

The good news is it is pretty easy to check if this is an issue – just create a user that doesn’t require the complex permissions model (give them global access to all of the necessary entities) and see if things are still slow. If not, it may be time to simplify your security model.

Uncached Header and Footer

As I discussed in my last post, the Web Templates used for the header and footer can be output cached. I’m not going to rehash the entire post, but at a high level, this means that very little of the code used to generate the header and footer needs to run each time a page is loaded.

I’ve seen this turned off for a few reasons, including that it makes development easier, or they are trying to use Liquid code to make the header or footer appear different to different users. Best practice (for performance reasons) is that output caching be enabled – so it is worth the effort to figure out how to meet your business requirements without disabling it. Consider the substitution tag mentioned in my previous post, or perhaps some client-side code.

Frequent Cache Invalidation

The Portal heavily relies on caching – if it had to go back to Dynamics each time it needed data, it would be very slow. When data is modified in Dynamics, the Change Tracking feature is used to send notifications to the Portal to let it know to invalidate that part of it’s cache. So, if you have some regular process that causes a bunch of entities used in the Portal to be modified, you’ll constantly be invalidating the cache.

For example, if you have a scheduled Azure Function that calculates the balance owed by a Contact every 5 minutes, and that code updates a time stamp on every Contact it processes, your Portal may effectively be operating as if it can’t cache contacts, which could lead to performance issues.

So keep an eye out for anything that might be causing the cache to be frequently invalidated.

Engage with Microsoft

If all else fails (or, even before), get in touch with Microsoft. If you can get access to a FastTrack engineer, even better! Microsoft has access to resources and statistics that no one else has that can be very helpful in diagnosing performance problems.

8 responses to “Dynamics 365 Portal: Where to Look When Things Are Slow”

  1. […] on a bit of a Dynamics 365 Portal performance kick these days. One tool I didn’t include in my post on where to look when things are slow was the Portal Checker, which provides a self-service way to identify potential issues with your […]

  2. […] on a bit of a Dynamics 365 Portal performance kick these days. One tool I didn’t include in my post on where to look when things are slow was the Portal Checker, which provides a self-service way to identify potential issues with your […]

  3. Jeff Loretta says:

    Came across your blog when searching for portal load speeds. We’re using a custom portal for an appointment booking application and are seeing slow load times. Just curious if anything can be done to speed things up.

    • Nicholas Hayduk says:

      Hi Jeff,

      It really depends on how slow things are. As I mentioned in the post, this is the fastest platform in the world, so multi-second page loads are the norm. However, things are taking double digit seconds or minutes, I’d say that there is some sort of underlying issue that is probably worth investigating.

      Are you issues when the pages loads for the first time, or when submitting data?


  4. Paul Chapman says:

    Hi Nicholas, thanks for this really useful post. We’ve just launched the Dynamics Marketing app, which gets wrapped in a (Events) portal. We haven’t done any fancy customisations to the portal, it’s basically OOOB. The issue we are seeing is when we first visit the Events portal, either homepage or a specific event. It’s taking around 12-14 seconds to show ANYTHING on the screen. Once it’s there, it’s reasonably fast. Thanks to your post we’ve tested the Change Tracking feature, and the header/footer are cached. I wondered if you had any pointers for the direction I should be looking (given it’s the initial load more than general run time). At startup no-one is logged on of course, so does that rule out a permissions issue? Any thoughts you have would be much appreciated. -Paul

    • Nicholas Hayduk says:

      Hi Paul,

      If this is the first time anyone has visited the page, 12-14 seconds would be expected. Is it quick to load after visiting it for the first time?


  5. Srilatha says:

    Follow these tips to increase your portal’s “speed” by reducing the cache discrepancy.
    Tip #1: Enabling/Disabling Change Tracking
    You can see this change tracking option under entity.
    You can access the Change Tracking option on each entity from the solution. Checking this option will allow the portal to refresh it’s cache on a specific entity, rather than attempting to re cache all of the data at once.
    What entities need change tracking enabled
    All custom entities should have change tracking enabled. Likewise, any entity that portal users will interact directly with should also have change tracking turned on.
    What entities need change tracking disabled
    Disable change tracking on the Web Page and Web File entities. These are entities that come with the Dynamics 365 Portals solution.
    Tip #2: Enable Header and Footer Cache
    By default, the Header and Footer web templates are rendered each time a page is loaded. By making a few adjustments to the Header and Footer Web Templates and then adding some Site Settings, we can cache the Header and Footer to increase portal speed. Visit this page and follow the instructions carefully to replace several lines of code and add the correct site settings, provided by Microsoft:

    Below document will be helpful to Enable header and Footer cache :

    Thank you & Regards

Leave a Reply

Your email address will not be published. Required fields are marked *


Engineered Code is a web application development firm and Microsoft Partner specializing in web portals backed by Dynamics 365 & Power Platform. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.