When developing extensions for Microsoft Dynamics 365, occasionally you will encounter errors with custom functionality, or even with built in functionality. Sometimes the accompanying error messages can be rather… unhelpful. Thankfully, those error messages usually provide you with an Id to work with. I’ve included a query below which finds the entity logical name associated with a GUID. This has been helpful for me in the past.
This is handy, but can take a wee while to run on larger systems. This method relies on a brute force approach to retrieve the logical name of an entity when you only have a Guid. This can be rather inefficient, but I currently do not have a better way to do this.
This is particularly helpful in the rare case when an error message or plugin trace gives you little other than a Guid. This primarily happens with plugins that run on Associate, or other messages that do not allow you to specify a primary entity for the plugin to run on. If a check for the entities involved is not comprehensive, it may lead to situations where you have a trace similar to: “record1=GUID”, with no context as to the logical name of record1. Any errors thrown by this plugin would then be difficult to debug as there is no context as to which entity ‘record1’ is.
There may also be a situation where you are dealing with legacy code that either has poor tracing or you do not have access to the source code. In this situation, this function, combined with access to the base solution of the system you are working on may give you valuable insight into what is causing the issue.
You may also use a variation of this when interpreting requests to APIs, for which the same API call might be used for multiple entities, but the logic might be slightly different depending on the entity the Guid belongs to.
