Michael Stavrou

This suggestion revolves around the automatic lookup "name" field resolution. I'm posting it under "customer service", but it's really about the broader Dynamics 365 CRM system logic.

How the platform works:

-----------------------

Every time an entity is opened (i.e. 'Retrieve' operation) or when multiple records are searched (view, advanced find, etc. i.e., 'RetrieveMultiple' operation) all the lookup names are resolved again. Even though in the CRM DB there are columns for both the lookup record id and name, the platform will always resolve those lookup names again.

This is understandable as the name may have changed in the interim, so it would be appropriate to show the latest information to the user rather than show them the old value that was populated when the parent record was saved. This is really useful as I've used this behavior multiple times when I wanted to translate lookup names for multilingual environments where each user wanted to see the values in their own language by creating the necessary retrieve and retrievemultiple plugins.

Issue Description:

------------------

Quite often the primary name of some configuration entities will really never change or very rarely change. Having an extra retrieve operation for those entities is an overkill that simply takes extra processing time and makes the user experience much slower. The worst part though, is when those lookups point to virtual entities. Each time they are resolved this is a call to another system to fetch their latest name. I have retail customers that have 5-10 lookups on the case and phone call entities in order to link the case to the ERP records the case is for. Each time the case is reasssigned or during resolution or even when an irrelevant field is updated, those lookups are again getting resolved resulting in extremely slow system response times for the end user. The names of those entities are really the order number, order line number, loan number, coupon number, etc. Names that are really impossible to change, yet they have to get resolved again on every operation on the parent entity. If all of them are populated that's 10 calls to an external system to get the data. Not to mention that if you add them in a view then that's 25-250 records that need to get resolved so that's another call to the external system.

Suggested Improvement:

----------------------

The ideal way to address this would be to have the automatic lookup name resolution on the entity level as a configuration. Just another checkbox to configure the desired behavior per entity. For entities were the implementer knows this is fixed data that never changes they can elect to turn this off and speed up the system. This doesn't need to be done only for virtual entities, it can be done for all entities in CRM. This would be the best way to address it. That way the issue for never changing lookup resolution can be addressed, especially for customers that heavily use virtual entities.

I would take it one step further for rarely updated ones as well and if the automatic resolution is disabled for one entity, then at the level of the parent record form show an icon next to the lookup to update the latest name. Similar to the behavior of roll-up or calculated fields.

The system performance improvement for virtual entity lookups will be massive if this is done.

There are plenty of OOB entities that take a considerable amount of dataverse capacity which is pretty expensive. In my opinion those tables should count as file storage which is cheaper since it's not real customer data but out of the box customization data that is required for the platform to operate. For example, I have 3 development environments where the "LocalizedLabel" table is taking 2GB per environment, "Attribute" table is taking over 740MB, "Plugin assembly base" is taking 500MB, "System Form Base" is taking 425MB, "Report Base" is taking 300MB, "Dependency Node Base" and "Dependency Base" are taking 245MB each, etc. Roughly 6GB per environment are dedicated to basic OOB entities that store solution component details. Some other entities have already been moved to the file store like "Solution", "Async Operation", "Web Resource Base", so I believe it's only fair to move all such entities to the file store instead of only some.

I've had a client that was forced to overwrite the entire OOB entitlement logic in the past because async operation was taking 100GB of storage to store the entitlement expiration and activation triggers. They opted with writing a service to delete the OOB triggers and expire them when the date came as Microsoft's official response was that this was by design. Then, the async operation table moved to file storage. If it was file storage from the beginning, they probably would have paid the price instead of moving to a custom solution.