When dealing with a system that involves many complex entities, we’re bound to have long entity names in Microsoft Dynamics 365. Longer entity names could be to further modularise separate functionality in the system without compromising the descriptiveness of the entity name. For example, you can have two entities in CRM managing an Analytical Dashboard website called “Analytical Dashboard User Settings” and “Analytical Dashboard Entity Settings”. This could be a problem when we want to create relationships between these two entities that have long schema names. This blog will demonstrate on how you can work around an existing out-of-the-box limitation given the assumption that you do not want to alter with Dynamics 365’s schema name generation conventions (will expand below).
To demonstrate this, I’ve created two custom entities with the given names above. Dynamics 365 will autogenerate the following schema names appropriately.
The out-of-the-box behaviour of creating relationships via create new 1:N Relationship record in Dynamics 365 is when you create a relationship from the Primary Entity e.g. Contact, and you need to set the Related Entity. Once we set the Related Entity e.g. Account, CRM would automatically generate the schema name of the relationship. The autogenerated schema name is a concatenation of the Primary Entity schema name and the Related Entity schema name.
I will create a new 1:N Relationship from Primary Entity “Analytical Dashboard Entity Setting” to Related Entity “Analytical Dashboard User Setting”. When we create the 1:N Relationship record from “Analytical Dashboard Entity Setting” and set “Analytical Dashboard User Setting” as the Related Entity, the relationship schema name is autogenerated but appears to be incomplete.
It’s evident that there is a 41 character limit for the relationship schema name field. This can be a nuisance, especially for someone like me who sticks to schema naming conventions based on how the system autogenerates and concatenates schema names.
The workaround to this underlying out-of-the-box behaviour is through creating a relationship via creating a lookup field. Creating a lookup field from the Related Entity (since lookup fields refer to the Primary/ Parent Entity) allows us to work around the character limit issue for the relationship schema name field. Creating a lookup field automatically creates a Relationship record between the Primary and Related Entity.
If we want to create a relationship via lookup field between Primary Entity = Contact and Related Entity = Account, we need to make a lookup field from Account, and set the Target Record Type (which is the Primary Entity) to Contact. Default CRM behaviour does the same automatic generation of naming fields with the addition of also concatenating the schema name of the lookup field (in the screenshot, this is the field schema name “Primary Contact”).
Now we can create our relationship for our entities with long schema names accordingly through this method. I’ve created the lookup field for the Related Entity “Analytical Dashboard User Setting”, set the Target Record Type to the Primary Entity “Analytical Dashboard Entity Setting”.
This time, the autogenerated relationship name returns what we would expect – no incomplete names when both schema names are concatenated. The generated relationship schema name “mig_analyticaldashboardentitysetting_mig_analyticaldashboardusersetting_MainEntitySetting” also includes the lookup field schema name “MainEntitySetting” which we can remove.
We can assess the relationship schema name further by checking the 1:N Relationship record that automatically gets created by the system. The character limit of entering the relationship schema name manually gets ignored as the field gets populated based on our created lookup field. Thus, we are able to have our intended relationship schema name between our two entities without compromising naming conventions.
Do note that the when creating the lookup field, a prefix will be added to the schema name by default. It is recommended to delete the leading prefix on the Relationship Name field when creating your lookup field e.g. ‘mig_’ in the autogenerated relationship name. This is to avoid having a double prefix name on the final product as shown in the screenshot above e.g. ‘mig_mig_ ...’