Dynamics CRM: Almost xRM

I’ve been getting some emails from readers praising some of the tutorials I wrote round Dynamics CRM customisation and wondering if I have any further tutorials planned. As a matter of fact I do – or perhaps I did. Upon examining some of the topics I was hoping to write about, I came to a poignant realisation: The vast majority of subjects I was hoping to write are about how to circumvent limitations of the Dynamics CRM platform.

As I investigated these limitations on forums, blogs and other sources about Dynamics CRM I can only conclude that Microsoft is doing little to nothing to address most of these concerns. I’ve been working with Dynamics CRM for years and I’m starting to feel as if Microsoft might be in denial about some of the feature requests they receive on Microsoft Connect website.

With all that in mind I feel that before I write any further articles about Dynamics CRM, I should write one article about the Dynamics CRM limitations I find intolerable. In case you’re wondering, I agree that this post has a “ranting” connotation. However I’d like readers to see beyond my frustration and consider the points I am raising as a way to encourage further enhancements on the xRM framework. I truly believe that if Microsoft follow-up on these issues, it will greatly increase the competitive advantage of Dynamics CRM to the point it will become the de-facto market leader.

Microsoft likes to refer to the Dynamics CRM customisation and development framework as xRM (anything relationship management), which implies that Dynamics CRM can be customised to meet most business requirements around a relationship management platform. In reality, whoever, I can’t recall an enterprise project that I have worked on where I didn’t have to pull a kludge because of limitations undocumented features in the platform.

One aspect of Dynamics CRM customisation that leaves me bewildered is the badly documented (or completely undocumented) limitations on custom relationships among entities. For example, the fact I can’t create relationships between the Address entity and any other entity, whether it is a custom entity or not. In my view this makes the Address entity useless, particularly for clients that work with ERP (enterprise resource planning) platforms and require some sort of integration with Dynamics CRM.

Moreover, I once found out the hard way (i.e. during the build phase of a project) that I couldn’t create many-to-many relationships between entities when one of these entities is an activity entity. More recently, I created a custom entity which should have a parental relationship with contacts (i.e. cascade delete), only to find out that I couldn’t have such relationship between contact and another parent entity.

Still on the subject of relationships, Dynamics CRM has a ‘virtual’ entity called customer, which points to both account and contact entities. Many system (i.e. built-in) entities have a relationship that point to this virtual entity, thus allowing one lookup field to point either to an account or a contact (e.g. opportunities, cases). I understand this has been created as a solution to satisfy both business-to-business and business-to-customer business models. However, we can’t expand further on the use of this customer entity. For example, Dynamics CRM doesn’t allow the creation of additional lookup fields that point to this virtual customer entity. Moreover, users can’t expand on this virtual entity to include other entities in addition to accounts and contacts.

What Microsoft should do is a way to allow system administrators to create more of these virtual entities. For example, when creating a case in Dynamics CRM, we might want a lookup field that would allow me to pick either an account, a contact, a supplier or a wholesaler; rather than a customer lookup where we can only choose accounts or contacts. This is particularly important in scenarios where we can’t accommodate different record types in just one entity (normally due to security role requirements).

Party list is another type of field that exists for certain system entities (e.g. email activities) but we can’t create through customisation. Party list works like a type of lookup that allows for multiple references to records of multiple types of entities to be set in a single field.

I do consider these limitations on the relationship framework to be quite a hurdle which unfortunately I had to face in more than one project. Dynamics CRM do have other limitations beyond the relationship framework which I would like to mention here as well. The fact that we can’t customise the system to allow or disable system views according to security roles can be quite a nuisance, mostly because users end-up with several views to choose from, when most views might be irrelevant to their security role. And since we’re on the subject, views are the only dataset that charts can be based on, which I consider to be a significant imitation for the creation of in-line charts (i.e. charts to be displayed in a form when opening a record).

Final Thoughts

My list of limitations is far from complete as there is always room for improvement. As you read this, I am sure that you have your opinion on something that Dynamics CRM might be failing to deliver which I haven’t mentioned. Feel free to chip-n in the comments section and I might even update this post and credit your contributions.

Having said that, I think these are the major issues that I currently find on Dynamics CRM which are most likely to give me headaches during extensive projects. In the end I do consider Dynamics CRM to be a great product. However as a solutions consultant and architect, I feel that Microsoft must framework enhancements a little harder in order to deliver the xRM promise. Ahhf! Now that I got this out of my chest, I promise my next post will be on a lighter, more positive note.