1 to 1 Relationships in Microsoft Dynamics CRM 4.0

One thing I’ve always wanted in Microsoft Dynamics CRM was the ability to create a one-to-one relationship between entities. According to the 8912 Customization in CRM 4.0 courseware, this is not supported. Keep in mind however, that many to many relationships were not supported in CRM 3.0, but we created them back then using a custom intersect entity and two or more 1 to M relationships.

I’ve given this a lot of thought, and it seems to me that you can create a one-to-one relationship using an interlocking pair of one to many relationships and two workflows to automate the link maintenance.

In this example, I wanted the ability to display outside contractors in the CRM service calendar while allowing CRM supported e-mail capabilities to communicate their task assignments. While CRM entities can support additional e-mail fields, I haven’t found an easy way to send e-mail to any e-mail attribute in CRM other than to  Users, Leads, Contacts, and Accounts (or UCLA coined by Janice Hunt, one of the participants in the December CRM bootcamp in Cary, NC).

We start off by creating a one to many relationship with Contact as the primary entity and Facility / Equipment as the related entity. Note that we do not display the unused ‘many’ side of the relationship by selecting “Do not display” for the Navigation Pane Item for Primary Entity section of the General Tab on BOTH relationships. I did this to hide both ‘Many’ sides of the new relationships (the Associated Records list) from the user to avoid confusion.

clip_image001

Figure 1

Next,we create the reverse relationship with facility/equipment as the primary entity and contact as a related entity. Again, we do not display the unused ‘many’ side of the relationship by selecting “Do not display” for the Navigation Pane Item for Primary Entity section of the General Tab on BOTH relationships to hide the associated records list from confusing the user.

image

Figure 2

This creates the relationship structure, but we need to tie up some loose ends with two workflows. To make the example work, each entity must point to the other as the primary entity.

So we create a workflow associated with the equipment entity with automatic options: scope — business unit, start when record is created and when record attributes change.

image_3

Figure 3

We select contractor as the only attribute that the workflow will monitor for changes, then click OK.

image_4

Figure 4

the first line of code is a check condition to see if there is a Contractor link to be maintained,

image_5

Figure 5

then to verify if it needs to be updated.

image_6

Figure 5B

If so, we need to update the contractor attribute of the contact entity to point back to this record, completing our one-to-one linkage.

image_7

Figure 6

When we publish this workflow, every time a new equipment record is created or the contractor attribute is changed, the resulting contact will also have its contractor attribute updated to point at the current equipment record.

To finish everything off and make the contractor relationship bi-directional, we need to create a second workflow associated with the Contact entity to  maintain the contractor relationship whenever it’s changed. Unfortunately however, when I went to do that I found that the equipment entity does not appear in the list of related entities. I republish both entities, only to find that the problem persists. When I tested this with a custom test entity and the contact entity, I found that the updates were possible on both sides which confirms that this may be a CRM imposed limitation related to the Equipment entity.

image_8

Figure 7

In this particular case, this leaves us with a semi-functional one-to-one relationship that only works properly when you maintain the link from the equipment form.  We will not expose the contractor relationship on the contact form, forcing all relationship changes to happen from the equipment record. Custom entities will not have this problem.

Now, workflow associated with either entity will support dynamic value access to to the opposing 1 to 1 entity attributes.

image_9

Figure 8

You also be able to access the opposing 1 to 1 entity attributes using advanced finds and system views.

The functional benefit of a one-to-one relationship is that you have more control which fields you can update and utilize from workflow processes, advanced find, and public views in Dynamics CRM 4.0.

Feel free to make any comments, suggestions or otherwise.

Merry Christmas, Happy New Year to all!!

Steve Noe, MCT

Advertisements

About stephenvnoe

Dynamics CRM solution architect, consultant, trainer & project manager. I provide CRM design, services, mentoring & support to all manner of Dynamics CRM projects.
This entry was posted in CRM, CRM 4.0, Customization, Intermediate, Training. Bookmark the permalink.

2 Responses to 1 to 1 Relationships in Microsoft Dynamics CRM 4.0

  1. Adnan says:

    Hi Steve Noe,

    I just saw your useful and helpful post. I would like to thank you for it. I was able to maintain something similar to a one-to-one relationship. However, I wonder if we can create a conditional one-to-one one-to-two etc… ie. say you have a custome entity called “Spousal Relationship” which can be Active -> Married, Common law etc.. or Terminated -> Divorced, Separated etc..
    a one to any relationship from “Contact” to “Spousal Relationship” with contact as a primary entity, as every contact can have many relation ships but should have at most one “Active” relationship. So if a CRM user, accidentally tries to create a new relationship for the contact and select “Active” the system should not accept it. For me this sounds to need some Javascript coding, correct? Or can we do it using workflows as well? Please note that in this case, my customer insist that both parties of the spousal relationship (both spouses) to have a contact record each in the same native contact entity? I am struggling with this!!

    Thanks!

    Like

    • stephenvnoe says:

      If you need to reject the relationship before the save, you will need to use jScript or a plug in. A workflow based on the relationship, (Not sure – Can you even do this?) would be able to refer to the 2 related entities after the fact and validaye or delete possibly. The latter is easiest to test so give it a try if you can manage it asychronously. SVN

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s