Tallan's Technology Blog

Tallan's Top Technologists Share Their Thoughts on Today's Technology Challenges

Using System vs. Custom Entities in CRM 2011

rlanzilli

I wanted to write about the topic of whether to repurpose system entities in CRM 2011 or create new custom entities. I know that there have been some blog posts about this before, but I can also reflect on this from personal experience.

There are many different points to consider when repurposing entities:

1. The out of the box functionality of the entity may not be exactly what you need. In these cases it might take a higher effort to modify and customize it then it would to start from scratch with a custom entity.

2. If you repurpose a system entity in CRM 2011 and package it in a solution, there is always the chance that another solution contains this entity. If these two solutions are imported into the same organization, this may cause a conflict.

3. You cannot change the icons for system entities. If it were repurposed, then you would be stuck with the original icon. This may not be a big issue, but there may be a time when this is necessary. There may be an instance when the repurposed entity has a completely different business meaning, and it may be confusing to some users.

4.You are not able to remove some fields on system entities. For example, on Campaigns you cannot remove the fields in the “Scheduling” section:

image

Sure you can set their visibility to false, but how much would have have to customize it before you can start using it? This adds to the overhead of repurposing an entity.

5. If you repurpose it now, then you would not be able to use it in the future. It is not always possible to predict the future, so keeping your options open is usually a safe bet.

6. Some system entities are significantly different from others, and you would have to know certain things in advance before using them. For example, on the Invoice entity it has a relationship with Invoice Products. If you were to repurpose those, you may not realize afterward that you cannot display Invoice Products on the Site Map (CRM 4.0).

In CRM 4.0, Invoice Product didn’t have a default view, and you couldn’t create a custom view for it.

image

This specific consideration has been changed in CRM 2011 as you can now add Invoice Detail to the Site Map, but there does not appear to be a simple out of the box way to add a new public view.

Invoice:

image2

Invoice Detail:

image3

7. Another example is when systems are integrating together. A financial software system may have the concept of an Account, but it may not be the same as CRM’s out of the box Account entity. Something as simple as this may lead to a low acceptance rate of CRM because the users may have to deal with a conflict of interest.

8. The final thing you have to ask yourself is why you want to reuse the system entity. Is there a definite set of functionality that can not be repurposed, or would it take effort to remove functionality?

With all of  that in mind, I do realize that sometimes there may be reasons to reuse an entity. For example, Account and Contact when you are deploying CRM for a Sales Team. But also consider that those entities were designed for Sales Teams. Account was not specifically designed to be used for Financial software, so that should be taken into consideration when repurposing entities.

Most of these examples will apply to both CRM 4.0 and CRM 2011.

Resources

http://blogs.infinite-x.net/2009/06/11/the-dangers-of-repurposing-existing-crm-entities/

http://blog.customereffective.com/blog/2009/09/the-crm-configurators-dilemma-repurpose-or-create.html

https://community.dynamics.com/product/crm/crmtechnical/b/mycrmopus/archive/2011/01/20/why-retrofit-system-entities.aspx

 

Robert Lanzilli (robert.lanzilli@tallan.com)

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>