CiviCRM Community Forums (archive)

Like many I am chewing on the pros and cons of implementing Households vs Individuals for a "family" of contacts. Here are some of the choice threads and blogs from my reading:

http://forum.civicrm.org/index.php/topic,8052.0.html
http://forum.civicrm.org/index.php/topic,9180.0.html
http://civicrm.org/node/558
http://forum.civicrm.org/index.php/topic,6727.0.html

Our use case is fairly straight forward: in our current database we have a family membership type which is linked to a single contact. Moving to CiviCRM we need to decide between:

1) Importing these contacts as Individuals, linking the membership to that Individual, and relating new Individual contacts which are part of the family to each other through a custom relationship, or...
2) Creating both Household and Individual contacts in the import, relating the Individual to the Household ("Household Member of"), and linking the membership to the Household.

Here are some implications I need help understanding which are not covered in the URLs above:

1) If we use Households, it appears that there is no equivalent to the "I am contributing on behalf of an organization." functionality for campaign/membership pages. Consequently any new membership, which is created by the user through an online campaign page, will be linked to the Individual and not the Family. And there does not appear to be a way to move a membership from one contact to another from the CiviCRM admin interface, which means that every time we receive an online family membership, not only will staff (or a hook) need to create a new Household, the online membership will need to be deleted and recreated on the Household and a soft credit will need to be applied to the Household (if you want an accounting trail).

On the other hand if the membership is linked to an Individual and other contacts are related to that Individual, the Individual  contact will be able to contribute/join/renew online, the membership will correctly populate under her contact record, and -- assuming the membership type and relationships are setup correctly -- the membership can be extended to the related contacts, correct?

2) When manually searching for duplicate contacts, the matching rules are specific to one type of contact. Through testing it looks like the contact matching rules apply across contact types (i.e. if you are creating a new Household and the email matches an existing Individual it will warn that there is a duplicate contact), but if we run the dedupe rules manually, the contact matching rules only match within the contact type associated with the rule. So if we use Household contacts for families there will be no way to manually find contact duplications if the duplicate contacts happen to be Individual contact types. Is my testing correct?

3) In the above URLs, the CiviCRM team recommends using Households for a family of contacts in use cases like mine. It seems like there are some disadvantages to using Households, what are the advantages?

jason

Hey Jason and Dave. I'm late but thought I would add my two cents.

It's no surprise but I don't think you should use households.  You should go the individual route for reasons already stated. I think there are limitations to using individuals but those aren't big enough to justify using HH's, in my opinion. When we started deploying CiviCRM, we used HH's and our clients are still suffering from that decision to be frank.

I think using hooks would be a timesaver for your admins/staff.  With custom fields you would ask people who their spouse is then the hook creates an individual from those fields and the relationship to the individual filling out the form, thereby extending the membership. We've never actually done this yet (not needed by our clients) but it seems doable.

Regarding the use HH address feature, as noted in my blog post, that's one area that should definitely be extended to all contacts (which is on the road map somewhere).

Not sure if this helps but I don't think your use case requires using HH's

Tony

You wlll need to do some custom coding with hooks to enforce the 2 person limitation (if it needs to be "enforced"). That said, one straightforward way to set most of this up in the UI:

- create a new relationship type => "Family Member"
- create two membership types: "Individual Membership", "Family Membership" - with the family membership configured to extend to related "Family Member"

With this approach, you can sign up a person for the Family Membership, and then when a "Family Member" relationship is created between them and another person - the other person inherits the membership.

Perhaps others will chime in w/ other approaches (based on real-world implementations)...