Dynamics CRM 3.0 was a good platform for building custom database applications. I realize that not everybody thinks of a CRM that way, but if you need to customize a CRM, and if your CRM stores its data in SQL Server like Dynamics does, it’s an important point.

 

Anyway, as good as CRM 3.0 was, the current 4.0 release adds some important improvements that might sound a little geeky at first, but actually solve some important and common business problems.

 

I recently recorded a troika of videos on the three major improvements, and I hope you like them:

 

While this is probably the geekiest-sounding of the 3, it might be the most useful. Basically, this lets you create a relationship (one to many) between an entity and itself. This lets you create parent-child hierarchy relationships between records. For example, a Case record might be the parent record of other cases; an Opportunity might have child opportunities associated with it.  Of course, once you’ve got this set up you can reporting and querying to see all of the relationships between existing records; but there’s another scenario where it’s even more useful: if you combine it with field “mapping”, you can have a nice simple approach to “cloning” records. Cloning refers to making a copy of a record in CRM — in 3.0 you needed code to accomplish this but if you combine a self-referential relationship with field mapping, you get this for free in the 4.0 version.

 

Anyway, here’s the video for self-referential entity relationships in Dynamics CRM 4.0.  

 

In CRM 3.0, you couldn’t create a new custom relationship between out of the box entities such as Account, Contact, Opportunity, Lead, etc. Basically, the idea was that any relationship you needed between these so-called “system” entities was created by the product team. In 4.0 this restriction is lifted and it’s an important improvement.

 

In the video on System to System Relationships in CRM 4.0, I show an example where you create new relationships between the User and Account entities, to implement a kind of a team approach for account management.

 

If you want a contact to be able to attend many events and an event to be attended by many contacts, you need a many to many relationship. In CRM 3.0, the only way to implement this was with two “one-to-manies”, using a so-called intersection entity such as registration. Essentially:

 

a 1:N from Contact to Registration

+

a 1:N from Event to Registration

= a N:N between Contact and Event

 

Sometimes you need this approach, since the intersection record can contain useful information (like registration status, payment, etc.).

 

But sometimes it’s overkill, and it’s always more complex than the new “native” many to many relationship you can implement in CRM 4.0.  In the video I recorded on Many to Many Entity Relationships in CRM 4.0, I go through an example where you want to track one or more “interest areas” for any contact in your CRM — you could use this to build marketing lists, for example.

 

Let me know if you find these helpful!