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.