I recently helped out on an issue with slow Dynamics 365 form loads. It was somewhat unique because the poor performance was only observed for one user, for one entity type(PhoneCall). However, every PhoneCall record that the user opened had the issue. We started with a somewhat typical approach investigating business rules, JavaScript, synchronous retrieve plugins, all the normal customization types we might see execute when a form loads. Disabling or removing any/all of them seemed to make no difference at all. We also investigated the roles/teams that this user was a member of, testing with other similar users and not seeing the same issue.
After some thought, we decided to query the UserUISettings record for this user/record type. This entity is used to store a record for each user, and each entity type the user accesses, the primary focus of each record is to cache the formxml from the last time the user accessed one of these records, and keep a cache of the records the user viewed, commonly referred to as Most Recently Used (MRU) data. This is displayed in the Dynamics 365 navigation in a dropdown next to the entity name, like this:
Since this issue affected only one user and for only one entity type, an issue with a UserUISettings record potentially makes sense here. I asked the user to query their UserUISettings for PhoneCall and send me the results. Here is a sample query they can execute in the browser to find this information out:
<org>.crm.dynamics.com/api/data/v8.2/userentityuisettingsset?$filter=_owninguser_value eq <user guid> and objecttypecode eq 4210
The column RecentlyViewedXml typically returns 5-10 recently viewed records in xml format, the xml will contain the datatype, primary name, id of the record. In the case of the user with the issue, the xml was very large, and contained 17,259 records. Trying to render this massive dataset in every form the user opened would almost certainly cause a performance problem.
It's important to mention that the application is in charge of keeping this xml a manageable size, and that there was an old defect identified that prevented this cleanup. That defect has long since been corrected in the application, however we've observed that if these records grew to an unmanageable size, the cleanup never happens or times out/fails. Therefore a one-time cleanup for affected users is a viable long term solution and not just a stop-gap.
One thing that makes cleaning up this data very challenging, is that it is stored in two places. First in the UserEntityUISettings record in the database like we discussed but it is also cached in Html DOM storage on the browser. You can see this by navigating to Dynamics 365, opening the f12 developer tools in your browser, and typing localStorage in the console and pressing Enter. This cache/database relationship is not one directional as you might think, but they actually try to keep each other in sync. Therefore, if we delete everything from the RecentlyViewedXml field in the database, the next time we access Dynamics 365, the browser cache will upload all the bad data back to the server and we won't observe any performance improvement. There needs to be a tandem effort to clear the localStorage cache and server data at the same time (or very close to it).
To assist with this effort, I created a solution that uses supported sdk methods to delete the data from the UserEntityUISettings record and clear the localStorage cache. Since it needs to execute on the browser of the affected user, there is a dashboard included in the solution that can be shared with users. When the user is instructed to navigate to the dashboard, they have the option of selecting an entity to clear the data for, or clear for all entities. The output window will provide progress updates and let the user know once the task is complete and they will not need to do any other steps like clearing history or closing the browser.
A view of the dashboard is included below.
Hope this helps,
Matt