MSCRM Best Practice - Considering Out-Of-Box Entities as preferred choice

I was working with one of my client where they have implemented Dynamic CRM for HR module. In a typical HR module the core entity is employee entity which is related with all other different entity such as Employee Leave Request, Employee Leave Approval, etc. I am not trying to explain how HR module works or any of its features in this blog post.

I would rather like to drive attention on how the approach and the mindset one must have for consuming out of the box entity and dynamic CRM functionality when implementing any business domain/vertical/module in Microsoft Dynamic CRM.

Account and Contact

Vanilla CRM comes with many default entities and the most crucial entities among them are Account and contact. The project that I was asked to review has implemented HR module in dynamic CRM and created employee as a custom entity, instead of considering contact to be as an employee.

• I am aware and understand that there is no direct employee entity that comes with vanilla dynamic CRM.
• Microsoft doesn’t have any guidelines which say when to use what entity.
• So it would be very normal for someone to simply go ahead and creates a custom entity for whatever purpose he likes.
• But the question arises - can we not use contact entity instead of creating custom employee entity?

Let’s talk about some of the pain that we may have to bear if we are not using core entities of dynamic CRM and creating our own custom entity instead.

Dynamic 365 portals / ADX portal implementation in near future.

Let’s consider after one year of implementations client ask to have employee self-login portal. We would be deprived with most of the features which Dynamic Portal provides as it has been designed by keeping core entities in mind.

If we consider contact entity for employee and install customer self-service portal, we would be benefited completely with most basic features which comes as out of the box.

1. Employee can login and manage their credentials and personal information like email and phone number.
2. The authentication and security model is all around contact entity and if we are not using contact and going with custom employee entity, then we need to have our own custom authentication and access management. This is re-inventing the wheel and waste of time and development efforts.

The list goes on as Dynamic 365 portal are purely implemented considering core entities in dynamic CRM. 

Marketing and Campaign

For campaign, we are supposed to create a marketing list and marketing list in dynamic CRM can only point to three entities which are Leads, Contacts and Accounts. There is no splendid path to bring a custom entity to be a part of marketing list. If we think of HR module where we want to inform employee about various organization policies could be easily achieved using campaign module. But this special out of the box features would be useless if we are not considering contact entity to be treated as employee entity.

Customer Service Modules

The service module in CRM evolves with logging of cases in dynamic CRM. By default incident and other related entities like entitlements are all related to contact and account entity. So again it is in our favor to stick with core CRM entities to enjoy the benefit of CRM completely.

No benefit of new features and Updates from Microsoft Team

Once we choose a path of creating a custom entity we start moving away from not only what’s been already provided in dynamic CRM, we also don’t get any benefit from a constant new features that are added by Microsoft Team and community. Any updates from Microsoft Dynamic CRM Development Team would be made considering the vanilla product provided not to any specific customer implementation.

Considering the use of out of the box entities and understanding vanilla CRM in its original form is also important to get best result implementing Dynamic CRM for any organization.

Regards,
Vipin Jaiswal
vipinjaiswal12@gmail.com