Import mapping suggestions

[commonpike]

Hi

I am in the process of mapping an existing database to civicrm for import. Obviously, there are some things done different in the old database than in civicrm. I imagine some of the questions that arise might be quite common, so I'll ask them here.


• display public profile: the old database had this as a field. would it best be a custom field or a tag, and why ? we will use this field for a drupal view, most likely, and some users may be eligible to change this field
• address name: like, 'munchhausen castle'. civicrm doesnt have this field by default, apparently ? i guess it should be a custom field
• Membership End Date: this is the date the membership ended, not the upcoming expiration date. there is no such thing in civicrm, so i'm curious how it should work here. if in civicrm these fields (expiration date and end date) are the same, how would i best import it from a database that keeps those separate ?
• is_student: would that best be a tag or a custom field ?
• is_selfemployed: i would reason, being self-employed is being an employee of yourself. but you can only be employed by an organisation ? is it a stupid idea to create an organisation named 'self-employed' ? what else would you suggest ?
• group role: in the old db there is a field specifying the role of an individual in something that i prefer to translate to a group in civicrm. what is the best way to specify this in civicrm ?

.. and more in general, if in the old db a field has a value 'Yes', and I want it to translate to another value within a specific field in civicrm (eg: Phone: 04567823), I would do such mapping in the csv before I import it. Is there a smarter way to do this ?

If anyone has some interesting ideas, I'd be happy to hear them !

thanks
*-pike

[JonGold]

Answers inline:

display public profile: the old database had this as a field. would it best be a custom field or a tag, and why ? we will use this field for a drupal view, most likely, and some users may be eligible to change this field

I think either is fine EXCEPT for your last requirement - users may be eligible to change this field.  I'm not sure this is even possible as a tag - it IS possible with a custom field.

address name: like, 'munchhausen castle'. civicrm doesnt have this field by default, apparently ? i guess it should be a custom field

This field exists in Civi, but is disabled by default.  Administer menu > Localization > Address settings, check off "Address Name" under "Address Editing".

Membership End Date: this is the date the membership ended, not the upcoming expiration date. there is no such thing in civicrm, so i'm curious how it should work here. if in civicrm these fields (expiration date and end date) are the same, how would i best import it from a database that keeps those separate ?

In what situation are these different dates?  Is this just a matter of current vs. expired memberships?  If so, I would merge the fields before import.

is_student: would that best be a tag or a custom field ?

Please don't ignore groups as an option!  Without more information about how you use this field, I can't really answer this, but this page should help you decide: http://wiki.civicrm.org/confluence/display/CRMDOC/Tags+vs.+Groups+vs.+Custom+Fields

is_selfemployed: i would reason, being self-employed is being an employee of yourself. but you can only be employed by an organisation ? is it a stupid idea to create an organisation named 'self-employed' ? what else would you suggest ?

See my last answer above.  It depends on how you intend to use it.

group role: in the old db there is a field specifying the role of an individual in something that i prefer to translate to a group in civicrm. what is the best way to specify this in civicrm ?

You can't attach metadata to membership in a group like that in CiviCRM.  Consider a custom field attached , or mapping the data in some other way (e.g. as a relationship).

Hope this helps!
Jon

[petednz]

Concur pretty much word for word with Jon. I would probably emphasise using Relationships too for the last matter. And using the Description field if you want to do something simple but nuanced eg

Officer for / Officer is ... as the Relationship Type - and then Treasurer v Secretary in the Description. ( or in a Custom Field on the Relationship)

Drupal Note: doing the above means you can easily display this in Drupal Views - not so easy in civi displays without some customisation