Using Custom Entities to Build N:N Relationships in Dynamics 365 for Customer Engagement
4 minute read
Often in the course of designing entity relationships, the need arises to relate multiple records of one entity to multiple records of another. For example, there are usually many doctors that work out of a hospital, and some of those doctors might work out of multiple hospitals. In this scenario, an insurance company trying to track doctors and hospitals would have a difficult time doing so without using an N:N (Many-to-Many) relationship.
Before we start, is your team looking for a managed services partner to provide post go-live support and preventative maintenance? For information on our 24/7 support contact us.
Dynamics 365 for Customer Engagement is capable of creating N:N relationships in much the same way that you create a 1-N (One-to-Many) relationship, the end result being that each record of your two entities can be related to multiple records of the other. To the user, both entities look no different from the “One” side of a normal One-To-Many relationship. This method is quick and convenient, but it does have some significant drawbacks:
- Creating Views and Charts that reflect the relationship is difficult, often requiring code.
- Out of box workflows can’t automate the creation of related records or the population of data as a result.
- There’s no way to customize the intersect entity to capture additional information.
If these are not important for the functionality that you are building, then definitely go with the built in N:N functionality. If they are, then consider building your own intersect entity instead. In the example below, we will build a custom entity to replace the out-of-box relationship between Cases and Articles.
- Create a new Entity: Case KB Article. Make the name field optional; we will not be needing it.
- In the Case KB Article entity, create a Lookup field to the Case entity and a Lookup field to the Article entity. Also, create fields for any other information you might want to capture. In this example, I’ve added an Option Set for “Usefulness” and an Option Set for “Clarity” to allow the user to rate each Article on a Case by Case basis. Place your fields on the form. You can make the Name field invisible if you like, as we won’t be using it. Don’t forget to Save and Publish.
3. Create a new View for Case KB Article, and make sure it has a lookup to the Article as well as any additional information you want to capture.
4. Edit your Case form and add a subgrid for the Case KB Article entity. Make sure you select the view you just created.
With that, your custom N:N relationship is complete. Let’s take a look at the result. In this particular scenario, our service representative has reviewed several articles in order to attempt to resolve the customer’s situation. In the process, he’s also noted how easy each article is to understand as well as how useful the article was for resolving the case.
And at the managerial level, we can use the data provided by service representatives on the usefulness and clarity of their resources captured on our custom intersect entity to decide where to place our efforts in reviewing and updating those documents. In the sample chart below, we can use the ratings provided by our service representatives to identify the Top 3 Most Useful Articles.
Using a custom intersect entity to build an N:N relationship between two entities takes a bit more effort than using built in N:N functionality of Dynamics, but it can have significant rewards for both the users directly using it and the managers leveraging the data. Consider building your own intersect entity whenever there is additional information you want to capture between two entities that doesn’t really belong solely to one, as well as any time you expect power users will be able to use the data to build their own views and charts.
For questions on relationships, please contact Hitachi Solutions today.
