locked
Custom entity or extend Lead entity RRS feed

  • Question

  • Hi.  what are the limitations on adding fields to the Lead entity in MS CRM 4.0? 

    I have already added about 50 fields to the Lead entity (10 to 40 characters each) but I now have about 100 survey response questions that I want to add to each lead.  Each answer is on average about 15 to 20 characters long and I'm concerned that adding this number of additional fields to the lead entity will impact on performance of the system.

    So, I wondered if I would be better of creating a custom entity linked to the Lead entity in which to store these answers?

    Any thoughts or suggestions please?

    Friday, August 5, 2011 4:03 PM

Answers

  • Here's my take, after having built a survey engine into CRM 4.0.

    1. Add everything to the Lead.  This makes everything easy for ad-hoc reporting and Advanced Finds and the like.  It does, however, mean you're pulling a ton more information when opening a Lead, which could have a performance impact on the server.  Also, it means that you can only ever have one survey response for a Lead (which may or may not matter to you).  It also means that every update to the Survey itself requires new fields, and possibly of old ones and the data they contain.  It's easy, but it's not flexible.

    2. Create a survey entity.  This is the way we went with the project I did.  It does mean more reporting overhead, as ad-hock reporting is more difficult, but it also means that you can support all kinds of response fields in a more dynamic manner.  We ultimately implemented radio buttons, picklists, etc in the survey. This manner is far more flexible, especially if you have to deal with more than one survey, or multiple surveys.  We ended up using the Campaign as out link to surveys, as that also allowed us to easily filter who had access to what survey (as we had all of this sync o a website).

    So you need to answer whether simplicity or flexibility is more important to the business case you're building the survey fields for.


    The postings on this site are solely my own and do not represent or constitute Hitachi Consulting's positions, views, strategies or opinions.
    Friday, August 5, 2011 4:27 PM

All replies

  • Here's my take, after having built a survey engine into CRM 4.0.

    1. Add everything to the Lead.  This makes everything easy for ad-hoc reporting and Advanced Finds and the like.  It does, however, mean you're pulling a ton more information when opening a Lead, which could have a performance impact on the server.  Also, it means that you can only ever have one survey response for a Lead (which may or may not matter to you).  It also means that every update to the Survey itself requires new fields, and possibly of old ones and the data they contain.  It's easy, but it's not flexible.

    2. Create a survey entity.  This is the way we went with the project I did.  It does mean more reporting overhead, as ad-hock reporting is more difficult, but it also means that you can support all kinds of response fields in a more dynamic manner.  We ultimately implemented radio buttons, picklists, etc in the survey. This manner is far more flexible, especially if you have to deal with more than one survey, or multiple surveys.  We ended up using the Campaign as out link to surveys, as that also allowed us to easily filter who had access to what survey (as we had all of this sync o a website).

    So you need to answer whether simplicity or flexibility is more important to the business case you're building the survey fields for.


    The postings on this site are solely my own and do not represent or constitute Hitachi Consulting's positions, views, strategies or opinions.
    Friday, August 5, 2011 4:27 PM
  • Thanks Wayne,

    Do you know if there are any physical limits on the number of fields that can be added to the lead entity?  I seem to remember reading somewhere that nvarchar fields take up a lot of space and so should be used carefully?

     


    Tuesday, August 9, 2011 9:12 AM
  • If I recall correctly, you can have up to 1024 Attributes on an entity.  So it's unlikely you'd hit that limit.  Nvarchar fields are the slowest field from a database perspective, so that is correct, they will have the greatest impact on loading Leads from the CRM UI, and also when doing reporting against your surveys.  

    If you're really going to be doing something that is going to take a lot of NVarchars, I would strongly recommend storing that information in a separate database and build reports that let people see that information in CRM.  Not going through filtered views will greatly improve performance on pulling that kind of information, with the downside being that you can't directly edit information in that other database from CRM without building some kind of interface. 


    The postings on this site are solely my own and do not represent or constitute Hitachi Consulting's positions, views, strategies or opinions.
    Tuesday, August 9, 2011 1:01 PM
  • Thanks Wayne.  I guess the Lead entity can handle my requirement then as it's only about 50 or so fields that I will be creating.
    Tuesday, August 9, 2011 1:05 PM