In this series on how Dynamics 365 Finance & Operations personalization affects performance, let's start with a couple of easy performance killers that require no tools but just common sense to deal with.

The first of these are pages with Live Tiles. This is standard functionality and very cool, but it tends to be abused. Remember each tile in your page (typically a workspace) is a query that needs to be sent to the SQL server and return results. If you have half a dozen then that's half a dozen queries on top of the default list. The biggest problem is however not the standard ones, but the fact that users can create their own. Users are typically not computer experts (citizen developers is nonsense) and if you look you will see (not surprisingly) that they sometimes create the most horrifying queries behind their tiles.

The next are FactBoxes. Some pages in Dynamics 365 Finance & Operations have a related information pane that shows read-only information that is related to the current record. You can expand or collapse these and these preferences are stored for the next time that you open the page. The app then has to retrieve the information for the FactBoxes if they are expanded, adding to the load the page places on the system. 

In both cases (as you should in most), when a user reports poor performance go over to them or do a screen sharing session (this is a really basic practice that seems to have fallen off a cliff) and see what the page looks like.

Does it have tiles? Then ask are they really useful. If not get rid of them. The nest step is check the query that is producing the tile, unless it's really simple (no joins for example, no complex where clauses) re-write it or get rid of it.

Does the page have expanded FactBoxes? There is absolutely no reason for this ever. Advise the user to collapse them, and always leave them all collapsed when leaving the form.

As with any other performance improvement you can make around personalization, expect push back from the users (you are taking their toys from them), so you need to explain to them the consequence and the reason why you are doing it, and in some cases you have to leave things as they are and accept the performance hit. Make sure it's communicated and accepted by the user community and management.