Dashboard > CRM > Requirements - ACTIVE Discussion and Revision > HouseHolding
HouseHolding Log In | Sign Up   View a printable version of the current page.

Added by Donald A. Lobo , last edited by David Greenberg on May 17, 2007  (view change)
Labels: 
(None)

Households - Storing Location Information and Communicating with Household Members

Use this page for discussion of current practices, and ideas for improving Householding support in CiviCRM.

A working specification for linking Individuals to Household Mailing Addresses has been posted to our Issue Tracker for implementation in 1.8. If you are interested in this functionality - please review CRM-1917 and add comments to the issue.

Problems with the Currently Available Functionality

From Sarmeesha Reddy (DharmaTech)

  • Scenario 1: we create a household and enter the home primary location with the household. We then create individuals, don't enter the same home primary location, and relate them to the household. When the end user goes to create a mailing and searches on just postal code, for example, then the end user gets a list of all contacts in that postal code with no duplicate addresses occurring from households and individuals related to that household. However, if that end user goes to create a mailing based on all contacts in the database, then they will get blank addresses for those individuals related to a household.
  • Scenario 2: If we enter the home primary location for individuals within a household and home prinary location for the household, then when the end user goes to search on the postal code, the search will return the household and the individuals within that household and the the end user ends up sending out multiple mails to the same place.

Current Practices

From Jay Davis (Atlanta Audobon Society)

We use households for snail mail addresses. So, when we send a snail mail mailing, we select from households. Our memberships are also tracked by household.

We use individuals, related to households, to track e-mail addresses and volunteer information. We figure that individuals volunteer, not households.

Right now, we have duplicate info in both households (i.e., e-mail addresses) and some individuals (snail mail addresses). I haven't
figured out how to address that just yet, but I figure I'll have to run some kind of update procedure to clean things up.

I'm planning to look into how to prevent certain info on the Household level and the same on the individual level. It would be nice if I could
define business rules and then make CiviCRM somehow conform to those rules (i.e., only Households have snail mail addresses).

From Elin Waring

Probably like Jay, we have everyone in a household and use the households for the most common mass snail mailing. People also have the same addresses in their individual records so that if they need a letter to them as individuals ( i.e. board members) the search and export is done at the individual level.

What you do is specify the type of contact when you search, so that you can get either just households or just individuals.

A harder issue is how to track contributions that are from households and for which the thank you should go to the household. Long term, it is better to (I think) to have the main credit go to an individual since then it will move with the individual if a household disolves. When soft credits come online as a feature that should help with this. The main thing is that we don't want to lose some's contributions just because he got divorced.

One thing I would really like is the ability to automatically generate a household for a new individual record.  Right now the work around for this is to import the relationship and use a name (like the first line of an address) for the household name.  

One reason we need address information for both types of records is that although household members may share a home address their work addresses will generally be different. Often,  there are people who prefer their 'business' mail to come to work, while their social/personal mail comes to the shared home.

Reasons households change:

  • Child moves out of parents home.
  • Child reaches adulthood and becomes a separate household even if still at home.
  • Divorce
  • Separation 
  • Marriage
  • Widowhood
  • Death--->I create a new record "estate of" to keep track of bequests.I have this as a different kind of relationship than household member of. 

 and so on.

(One nice thing in eTapestry is that when you change an individual address it asks if the household address should be updated and vice versa. )

Ideas for Improved Householding Support

Option to "Use Household Location" for Individuals (David Geilhufe - CivicSpace Labs)

  1. There is a reserved relationship type for households: A Household member B // B Member of Household A
  2. IF a household relationship type is specified for a contact, an individual contact can have a simple checkbox for each location "[X]
    use household location"

Current Data Model (Dave Greenberg - CiviCRM)

There is a set of properties in the civicrm_individual table which was added a while back which I think can be useful for controlling communications:

  • mail_to_household_id
  • phone_to_household_id
  • email_to_household_id

The planned usage is that each of these fields is populated with a household contact id IF communication of that type should be directed
to the household instead of the individual.

Configurable Restrictions on Permitted Data for Individuals vs. Households (Jay Davis - Atlanta Audobon Society)

I think it would be more useful to somehow define which kind of data gets put in which type of contact record.

For example, our organization has decided to only allow snail mail address data at the Household level. I would like to make it impossible to put that data at the individual level.

(Even if a Household dissolves, then the new individuals will need new Households, even if there is only a one-to-one relationship between Household and Individual.)

Likewise, in our case, I would like to restrict e-mail addresses to individuals.

So, as a high-level requirement, I think it makes sense to be able to restrict data to one or the other contact type.

Also, I think it makes sense to require that all Households have at least one Individual member. On creating a new Household/Individua record set, both new record types should be created, with the appropriate data saved in the appropriate record type.

Display Household Location When Viewing an Individual (Larry Hedrick - DharmaTech)

I tend to agree with your idea of having a policy which when enabled will disable the ability of an individual to hold a postal address. I am trying to break the idea but at this point I can't seem to come up with a reason this would cause a problem. I also like the idea that an email id is only bound to the individual, the same for phone. This brings me to the point that a household entity is only tied to a location. Should the individual record be populated with the household address for display, if this is the case the user will not need to look at the household relationship. Otherwise, Users will need to be trained to look at the members for detail information.

 type of communication control needed

David G., I agree with Larry and would go with your #2 option "[X] use household location"

Dave Gre., for 99% of the small to medium-sized orgs we work, the "use household location" type of control is really just relevant to snail mail / physical address. We haven't seen much of a need around control for phone and email to household id.

Powered by a free Atlassian Confluence Open Source Project License granted to CiviCRM . Evaluate Confluence today.
Powered by Atlassian Confluence 2.7.1, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators