Polymorphic Lookup in Dynamics 365: Streamlining Your CRM with Flexible Relationships

In Dynamics 365, a Polymorphic Lookup is a powerful feature that allows you to associate a single lookup field with multiple different entities. This feature is particularly useful when you want a field to reference multiple related entities, providing greater flexibility and efficiency in your CRM applications.

What is a Polymorphic Lookup?

A Polymorphic Lookup is a special type of lookup field that can refer to multiple entities rather than just one. For example, a single “Related Entity” field can refer to either a Contact, Account, or Opportunity, making it versatile for various business scenarios. This capability is referred to as “polymorphism” because the lookup field can resolve to different types of entities at runtime.

Example Scenario:

Consider a sales scenario where a “Related Entity” can be a Customer, but the customer could be either an Account or a Contact. Rather than having two separate lookup fields (one for Account and another for Contact), you can create a polymorphic lookup field, which makes your user interface simpler and more streamlined.

How Does Polymorphic Lookup Work in Dynamics 365?

In Dynamics 365, polymorphic lookup fields are implemented as part of the Relationship between entities. The key concept here is the EntityReference, which dynamically resolves to the appropriate entity type (e.g., Account, Contact, etc.) based on the actual value selected by the user.

  1. Field Definition:
    • When defining a lookup field, you define a Relationship where the field can refer to multiple target entities.
    • The system uses the Type and Id to determine the related entity.
  2. Lookup Resolution:
    • At runtime, when a user selects a value in the polymorphic lookup field, the system dynamically resolves which type of entity to link to.
    • The field displays the appropriate name (e.g., Account or Contact) based on the entity that the user selects.

Creating Polymorphic Lookups in Dynamics 365

Polymorphic lookup fields are typically used in the following types of scenarios:

  • Custom Relationships: When you need to create a lookup that can reference multiple different entities.
  • Shared Relationship: For cases where one relationship applies to more than one entity, such as a lookup that could refer to either a Contact or an Account.
Steps to Create a Polymorphic Lookup Field:
  1. Navigate to the Customization Area:
    • Go to the Settings area in Dynamics 365 and select Customizations.
    • Select Customize the System to open the solution where you want to add the polymorphic lookup field.
  2. Create a New Field:
    • In the relevant entity, click on Fields, and then select New.
    • Choose the Lookup data type for the field.
  3. Define the Polymorphic Lookup:
    • Under the Related Entity section, select Custom to define the multiple entities this lookup should support.
    • Select the Entity Relationships where this lookup should point to multiple entities.
  4. Save and Publish:
    • Save the field and publish your customizations to apply the changes.

Example: Setting Up Polymorphic Lookup for Customer

Suppose you’re designing a custom Case entity and you want to add a lookup for the Customer. Instead of creating separate lookups for Contact and Account, you can create a polymorphic lookup that links to either an Account or Contact as the Customer.

Steps:
  • Create a Customer Lookup field in the Case entity.
  • Define the Customer Lookup field to support both Account and Contact entities.
  • After publishing the field, the user will see the lookup field and will be able to choose either an Account or Contact as the Customer.

Use Cases for Polymorphic Lookup

  1. Consolidating Related Data:
    • Polymorphic lookups help streamline user experience by consolidating multiple lookups into a single field, especially when dealing with common relationships across different entities.
  2. Reducing Redundancy:
    • Rather than having separate lookup fields for Account and Contact in every related form, you can reduce redundancy by using polymorphic lookups, which allows referencing both entities in one field.
  3. Improved Reporting and Analytics:
    • When data is related across multiple entities, using a polymorphic lookup can make it easier to pull reports and perform analysis without requiring multiple joins or complex queries.

Considerations and Limitations

While polymorphic lookups are powerful, they come with certain limitations:

  • Limited to Certain Fields: Polymorphic lookups are supported only in certain system fields (like Regarding in activities), but may not be available for every custom scenario.
  • API Handling: When working with the Dynamics 365 Web API, the polymorphic lookup is handled through special attributes that require careful parsing to identify the correct entity type.
  • UI Considerations: Although polymorphic lookups streamline the user interface, they can also confuse users who are unfamiliar with the concept. It’s important to have clear documentation and training for users on how to use these fields.

Conclusion

Polymorphic lookups in Dynamics 365 provide an elegant solution for scenarios where a lookup field needs to refer to multiple entity types. By understanding and using polymorphic lookups effectively, you can streamline your CRM solutions, reduce redundancy, and improve your application’s flexibility. It’s important to consider the limitations and ensure that users are properly guided in utilizing these fields within your system.

You can easily create this Polymorphic Lookup from XrmToolBox as well…

https://pascalcase.com/Home/Blog/understanding-and-using-polymorphic-lookups-in-dynamics-365-with-xrmtoolbox

Hope this helps.

Cheers,

PMDY

All you need to know for migrating your Power Platform environments from one region to another

Geo Migration is a great feature/flexibility offered by Microsoft for customers who wish to move to a region which is in closest proximity to their operations even though initially their Power Platform environment region based out of a different one when they signed up. I checked out online but couldn’t find a good reference blog article yet online, hence this post.

I will make this post detailed but a comprehensive one for anyone to understand the migration. Customers can also opt for Multi Geo for those who have a need to store data in multiple geographies to satisfy their data residency requirements. If you don’t know where your Power Platform environment resides, you can check from Power Platform Admin Center.

If you were not aware yet, Microsoft Azure is the only cloud provider which offers services in more regions when compared to AWS (Amazon Web Services) and GCP (Google Cloud Platform). The Geo Migration feature seamlessly allows customers to move their environments in a single tenant from one region to another. e.g. for Singapore, it is as below.

Important:

  1. Geo Migration is not generally available, so please exercise with caution.
  2. You may reach out to your TAM(Microsoft Technical Account Manager) quoting your request
  3. There were several limitations, see below references for more details.

Mandatory Pre-Migration Check list:

  1. Any Power Apps, Power Automate Flows should be manually exported prior to the migration. Custom Connectors aren’t supported as of now, they must manually reconfigure or created in the new environment. You can export them individually or export them in group.
  2. Canvas Apps, Custom Pages, Code Components like PCF and libraries should be deleted from the environment before your migration activity starts. Else they might be in corrupted state after migration activity.
  3. If any of your Apps are not solution aware because of any reason like App calls a Power Automate when a button is called etc., you may need to explicitly export it out and take the backup.

Post Migration Check list:

  1. After the migration, import all the packages which you have taken backup during pre migration. For those which were not solution aware, import them manually.
  2. If you have Power Portals or Power Virtual Agents, those should be exported explicitly.
  3. Make sure you test all functionalities in order not to impact end users.

Notes:

You don’t need to build Apps and Flows from scratch. Dynamics 365 marketing App is not supported yet. There could be some configuration changes post migration.

While I try to put the information to the best available as per sources from Microsoft, this may change over time and variation could be different as each customer will have different workloads and dependencies with other services, so please read the references carefully before proceeding. Contact Microsoft Support or TAM as necessary.

Hope this helps to get a sneak peek into the migration process.

References:

Where is your data stored?

MultiGeo Architecture

Dynamics 365 & Power Platform new regions

Advance Data Residency Move Program

Geo to Geo Migrations

Cheers,

PMDY