RSMUS.comWith the introduction of Microsoft Dynamics CRM 2011, one of the new features was the Connection entity. The purpose of Connections is to provide the user with “loose” relationships between entities without having to set up an actual one-to-many or many-to-one relationship in the system. For a recent client, we determined that leveraging this functionality would be great for having contacts, system users, providers, and individuals having multiple connections to multiple individuals. For example, a contact in the system could be the guardian of one individual while also being a friend to another. From the front end this works great, but on the back end I faced some challenges that I’ll now address.
When CRM creates a connection between two entities there are actually two records that are created. There is the one that the user sees in the user interface (UI) in which they are specifying a connection to entity A from entity B. Automatically, another record is created that specifies a connection to entity B from entity A. From an event handling standpoint this involves a Create message and two Update messages which results in a plugin or workflow listening to the creation and update of a connection executing three times! The question you may be asking is “Well how am I to know which execution context I need to handle?” I’m glad you asked, the answer involves following two guidelines:
- Do not listen for the create event of a connection – This may seem strange based on experiences you may have had with developing business processes for other entities, but Connections aren’t just any entity. Listening to the two updates that occur after the connection is created will give you all the information you need and cut out the confusion of a 3rd execution context.
- Leverage record1objecttypecode – This is the schema name for the connected from field on the connections form. The connection we should be concerned with is the one the user created and from my experience most CRM implementations are account-centric. So in the beginning of your process filter for the connection with a record1objecttypecode of 1.
By following these guidelines, the system architect will have filtered the confusing three execution contexts down to one and as a result, will be able to provide users with complex solutions to their business needs that Dynamics CRM 2011 cannot handle out of the box. In my case, I was able to create related entities based on a filtered subset of connections.
I hope this provides much needed insight into the framework of connections for consultants in the future. If you have any questions or comments post them on the blog or contact me at Brendon.colburn@mcgladrey.com.
By: Brendon Colburn – Virginia Microsoft Dynamics CRM partner
