CiviCRM Community Forums (archive)

We want to use a Wordpress-based version of CiviCRM, however we have about 60+ different fields per contact.

Does CiviCRM support this? I was reading somewhere that it supported a max amount of 40 fields.

These are all the fields:

Date   Sources   Coder   Restricted   ID    Bar No.   Admission Date   SBM Voluntary Inactive   Born   Inception    Expiration    [Reserved]   Relationship Manager   Client Rating   MH Rating   Type    Last Name   Mailing Name   Employer   Position   Mail Line1   Mail Line2   City   County   State/Province   Postal   Country   Phone    Email   Website   EDU Law1   EDU1 Degree   Honors   EDU1 Degree Date   EDU Law/Grad2   EDU2 Degree   Major   EDU2 Degree Date   Other Law/ Graduate School   Degree   Major   Date   Undergraduate   Degree   Major   Date   Donor Pre99   Donor99   Donor00   Donor01   Donor02   Donor03   Donor04   Donor05   Donor06   Donor07-08   Donor09   Donor10   Donor11   Donor 12   Donor Rank   EDUMedia1   EDUMedia2   SuperL   Chambers   Best   dbTop   Bar/Group   Bar Assn Section   Ethnic/Affinity/Social Group   NonMich Admissions   IP   LAA-BOV   Primary Practice Area   Secondary Practice Area   Registration   Legacy   LR/MC   Coif   Key   EDU Scholarships/Honors   Past Positions   Comment   Military Service   Languages   Prior Name   Family   Representative Clients

Hey there Adam,

How familiar are you with the way that CiviCRM stores data.  It looks like some of your fields, e.g.

Donor99   Donor00   Donor01   Donor02   Donor03   Donor04   Donor05   Donor06   Donor07-08   Donor09   Donor10   Donor11   Donor 12

might actually not be custom fields but contributions.
http://book.civicrm.org/user/current/organising-your-data/overview/
http://book.civicrm.org/user/current/organising-your-data/mapping-your-data/
and a few other chapters would be worth reading.
Also havin a look at how data is stored in the demo site might make things a bit clearer.

For each of your fields that you have, I would do a mapping that includes a description of what they are used for and the place that you think they should go in CiviCRM.  If you want to share that, people on the forums might be up for commenting / helping you out to make sure stuff is going in the right place.

In terms of how many fields CiviCRM can support the underlying restriction is mysql - it depends on what type of fields they are and how long each is. in practice, i don't think people have problems unless they have multilingual support in many languages and long fields (since you can then approach the mysql row size limit - but it doesn't happen often in practice and you can always split out your fields into different data sets, each of which corresponds to a different mysql table, if this does become a problem.

Hi,

If you encounter a problem, it's much much more likely because you're trying to store the data in the "wrong place". As michael pointed out for instance, the donorXY fields shouldn't be custom fields, but separate contribution records (and/or membership?).

The demo should give you a sense of what goes where. If you can afford it and want to save time, hiring someone to help you for that mapping would probably avoid some pitfall and let you start with a better organised CRM from the start and quicker.

X+

And some others (like languages) are better solved using CiviCRM groups or tags.

So to reiterate: lost of fields possible but if you add all your fields as custom fields you are seriously misusing CiviCRM and will get into all sorts of functional issues although it is technically possible. If you feel unsure about this all, please contemplate hiring an expert?
(check http://civicrm.org/what/experts)