The Microsoft Dynamics CRM Blog
News and views from the Microsoft Dynamics CRM Team

The CRM Configurator’s Dilemma: Repurpose or Create?

The CRM Configurator’s Dilemma: Repurpose or Create?

  • Comments 4

image Today’s guest blogger is CRM MVP Joel Lindstrom who discusses tips and tricks when working with system entities. Joel blogs at CustomerEffective.

As you configure Microsoft Dynamics CRM, one question that frequently arises is should I create a custom entity or repurpose a system entity.  By “repurpose” I mean take an entity that is designed for one purpose and modify its fields and form to serve a different purpose.    Say you are configuring CRM for a property management company.  There are no system entities in Microsoft Dynamics CRM called “properties” or “leases,” but there are entities that are somewhat similar, such as Contracts and Opportunities.  It can be tempting to say “I’m not doing sales opportunities, let’s repurpose the opportunity as the Property entity.”  The perception is frequently that adding additional entities will complicate the configuration. 

Before you repurpose system entities, you should first consider several things:

1.  Consider the future—is there any chance that you might need the entity in the future?  Sure, you might not use sales opportunities right now, but can you say for sure that there is no chance that another department might not see what you are doing in CRM and decide that they want to use it too?  If you repurpose a system entity and later have a need for it, you will paint yourself into a corner and make it very difficult to impossible to change course down the road.

2.  Consider the overhead—While the perception is that repurposing system entities will simplify a CRM configuration, frequently the opposite is true.  In the example of the property management company that repurposes opportunities for properties, by doing so they are bringing many unnecessary fields into their property configuration, some of which cannot be removed from the form (such as price list, is revenue system calculated, and the convert to order button).  Other system entities such as campaigns, cases and contracts all have fields like subjects and date fields that can’t be removed from the form.  Sure these things can be hidden using JavaScript; however, that will add a lot of unnecessary complexity to the configuration when compared to a custom entity with only the fields and links that are necessary, and the more JavaScript you add to repurpose entities, the more things you will need to test and potentially re-do the next time you upgrade.

3.  Consider the user experience—due to the added overhead of a repurposed system entity, typically a custom entity containing only the fields and links that are necessary will be more user friendly than a repurposed system entity.  Take a simple example, like the entity icon.  Microsoft CRM does not allow you to modify the icons of system entities, so when you repurpose a system entity, your property entity will still have the standard CRM Opportunity icon.  This can be very unintuitive for users.  A custom entity, however, can have an icon of a house or office building, or whatever makes the most sense.

Simplicity in a CRM configuration is not determined by the total number of entities in the system, but rather in how they are presented (or not presented) to users.  Really no user should see every entity in the system when they log in to CRM—they should see only what is necessary for them to do their job.  Adding custom entities will not complicate their experience, especially if you remove the unused system entity links from their view.

In case you don’t know how to do this, here are some related links:

Cheers,

Joel Lindstrom



  • Senior CRM Developer's Quote of the Day

    "I would not give a fig for the simplicity this side of complexity,

    but I would give my life for the simplicity on the other side of complexity."

    Oliver Wendell Holmes

    Sometimes you have to move through complexity to get back to simplicity. Just as all those olympians make their sports look oh so easy :)

  • I completely agree with this guidance.  It is very similar to a blog article I published earlier, but only covered leads/opportunities/contacts:  http://www.shanmcarthur.net/crm/articles/guidance-on-the-use-of-crm-leads-and-contacts

    I have to fix so many user customizations from people who repurpose existing entities for other uses.  It is not fun.

    Shan

  • Great comments - I see this with customers all the time. Some customers insist we repurpose while other insist we create new entities.

    Couple of small points to add. If an organization uses relationships roles, they can only be defined between, accounts, contacts and opportunities. This might give one reason to repurpose account, contact, or opportunity so you can use relationship roles. Also you have some built in reporting and CRM behavior for rolling up data, looking up a customer (account or contact) and many other default behaviors. If you have to rebuild this because you created a new entity for what is truly your organizations customer you might be building more then a new entity.

    Our practice has always been to evaluate the pros and cons of the design and move forward. I do not believe it’s faster to repurpose or to build, its equal effort. But if a new entity requires writing a lot of code to role up data, report, create advanced finds or create relationship roles it might be easier to repurpose.

    Thanks for the great article.

  • I've been thru that dilemma, one problem is I can't create the multi entity select fields when you want to link an entity to either an account or a contact.

Page 1 of 1 (4 items)
Leave a Comment
  • Please add 4 and 3 and type the answer here:
  • Post