of the
Last week I was in a discussion with a colleague and the topic of whether or not he should re purpose the opportunity entity came up. He had a scenario that was somewhat similar to opportunities, but was not a sales opportunity. This lead me to rediscover a blog post I wrote 8 years ago for the Dynamics team blog called The CRM Configurator’s Dilemma to answer the question “should you re-purpose system entities or create new entities?”
My advice from the post, with updated comments:
- Consider the future
Still valid, even more so. The future of Dynamics is moving much faster than it was back then, using entities in non standard ways can cause problems if Microsoft makes changes to the entity that you are using. Also, if you choose to re-purpose a little uses system entity like contracts, there is a good chance that Microsoft will elect to deprecate that entity in the future. Custom entities don’t get deprecated.
2. Consider the overhead
When I wrote the original post, there were a number of system entities that had certain fields that could not be removed from the forms. This has changed somewhat as system entities have been refreshed and modernized, but there are still fields on entities like opportunity, case, and campaign that cannot be removed from the form.
3. Consider the user experience
This still applies–if your use case is less that 50% in line with the standard entity functionality, a custom entity will typically give users a more simple user experience than scaling down a more complex system entity. Plus we now have the ability to add business process flows to any entity, including custom entities, which can easily make a custom entity use experience as good or better than re-purposing a system entity.
Final thoughts
The advice 8 years later is still the same–don’t re-purpose system entities. There is even less reason to do so now–one of the biggest reasons that configurators 10 years ago would re-purpose system entities was activities–users wanted an activity type that wasn’t a fax, email, appointment, or task, so the configurator would grab one that wasn’t being used and re-purpose it. Now we have custom activity entities, this is no longer necessary.
Good advice Joel, I would agree with you here, however the devil is often in the detail.
When your “use case is less than 50% in line with the standard entity functionality” is often a very hard call to make. Is it based on current requirements only. Going custom are you ruling yourself out of potential future enhancements to system entities?
Also, don’t forget the potential licensing issues / benefits with going with a custom entity versus a system entity.
We performed a deep dive into some of these issues in our comparison of Case v Custom entity here :
https://dynamics365heroes.com/2017/07/10/case-v-custom-entity-part-1-lets-fight/
and a looked at some of the licensing implications here
https://dynamics365heroes.com/2017/07/24/case-v-custom-entity-part-2-licensing-considerations-decision-matrix/
Thanks Brian,
I agree there are always exceptions to rules of thumb. Reading your posts, it sounds like you are talking about whether to use Cases or a custom entity for case type records. In that example, I would use cases (if it walks like a duck…). What I was talking about is say you want to have an entity to store pets in and decide to repurpose the case entity–that is totally different use case than a CASE.
So when I say don’t repurpose, I’m not talking about a simplified version of the same thing, I’m talking about using an Orange for a Watermelon (opportunities vs. properties example).
What are the licensing issues you talk about? Team member licenses can access custom entities, but cannot access certain system entities. So from my perspective, custom entities are more favorable from a licensing perspective.