Households – a bit of an audit

2010-08-25 21:25
Written by

We have been looking at whether it is a good idea to use households and thought I would pull together the various things that have been written about households into a bit of a 'where are they at'. This is somewhat timely as there are a couple of things on the roadmap for 3.3 which have relevance to households – allow shared any contact to share address with any contact (if implemented this may cause some people to choose not to use households) and allow Custom Data to be exposed via profile for on-behalf-of organisation (status of this is currently seeking funding but if this were available to households and other relationships this might solve some of the major problems with households – in particular if it also allow updating of shared addresses).


It should be noted that some notable CiviCRM consultants (Tony ex Dharmatech, Eric and Michael McAndrew ‚- see links at end) have considered this question before so my goal in writing this is as much to look at where others got to on this question and see whether anything has changed. When I was thinking about this I could think of a number of ways in which households and organisations had different functionality but I couldn‚Äôt think of a single example where it wouldn't be better if both had the same functionality.


So, first up the question is what benefit might there be in using households. The two main areas where using households has potential are:

  • address management

  • viewing households as a financial entity

  • transitive permissioning

(who said I could count – heck – I don’t even understand what orthogonal means)


Address Management

This is the main functionality of households that is implemented in CiviCRM. The idea of course is that if Mr & Mrs Smith share a household (live together) and Mr Smith moves then Mrs Smith and Baby Smith should also have their addresses changed. So, in this context using a household address helps to ensure that all household members have their addresses updated. Usability questions relate to :


  1. How you add and update the household & household address through the back end

  2. How you add & update shared address records through front end forms

  3. How you ensure a family only receives one copy of a snail mail and that it is appropriately addressed

  4. How good is searching and reporting on households

  5. What are the implications of households vs individuals on Civi-Engage?

I will come back to all of these as this is the crux of the discussion and I want to comment on the other 2 (I’m sure I counted right – Luke was helping – and he can count to 11)


Viewing households as a financial entity

This is an area that has come some way since Tony’s thoughts on it – due primarily to CiviReport and soft credits. Donations from family units are often that – from family units rather than one of the individuals within it. Soft-credits are a great way to represent that. There are two ways to use them. One is to soft credit from Mr Smith to Mrs Smith and vice versa. The other is to soft credit from both to the Smith household. This latter option allows more consistent reporting – the existing soft credit report and the existing household summary report both give useful reports on the household’s contribution (once you change the relationship in the household summary from the old-fashioned ‘head-of-household’ to family member.) It also steps around the problem of more than two members of a household contributing – since you can't soft credit to more than one contact.


The downside to soft-credits is that if you want to apply a consistent rule to front end entries you need to probably implement a custom hook. However, this is not a major and applies to either approach.


Households in this context allow you to track more than two people in a household making financial contributions.


Transitive permissions

This is the idea that if you have permission to edit your household and your household has permission to edit your daughter you have permission to edit your daughter. This is potentially useful in the context of households and organisations and we have implemented it for customers. We haven’t had a mandate of support to submit it as a patch as yet.


Back to address and data entry management


Managing shared addresses through the back-end


Currently you need to create the household before you create the individual which is a bit cumbersome. (We are pretty sure this worked previously ie you could create the Household Address from the Individual record). It's also not possible to edit the household address from the individual.

Managing shared addresses through front end forms

There is currently no way to do this – ie if a Contact who is using Household Address gets to a form that shows their 'address' and they update it, then it does not affect the Household Address. They still show as having a 'shared address' but the addresses are now different. Also, there is no way for them to indicate whether their address should be divorced (maybe an appropriate word) from the rest of the household address or if the household address is changing. The specification for the 3.3 changes to shared addresses does talk about managing this but I'm not sure if it applies to front-end profiles/ forms of just back-end.


Another issue for households is thatu4 people will not be added to households as a result of filling in a front end form. This does not apply equally to organisations as the current employer field is ‘special’ and creates the relationship.


Ensuring only one copy of a correspondence is received and that it is appropriately addressed

I believe most of the problems here have been ironed out.


How good is searching are reporting on households

My impression is that this is not a problem area – unless you use a mixture of individuals with households and individuals without households – in which case you will need to include both within searches and reports which may lead to confusing results.


Writing this has highlighted for me the difficulties in managing related contacts in general – especially with regards to shared addresses and allowing people to update both contacts from one place.


My feeling is that if we are to use households then we should probably create a household for every home in the civicrm database (whether there is one or more people in it) or else we will be faced with walklist reports and financial reports that mix and match the two. However, this would probably require hooks to create households for each individual in the DB who doesn't have an existing household on data entry and more confusingly, to handle households breaking up & getting together.


Assuming that the shared address feature planned for 3.3 covers all relationship the primary argument for households is likely to be dealing with them as a financial entity and being able to track all of a households contributions. It seems that if it were possible to 'collate <whatever> on shared addresses, then households will really add no extra value at all. By 'collate on shared address' I am thinking of the way in which exports allow you to 'merge on shared address'. If contribution reports / pdf letter functions allowed this I think households would be redundant.


Related links,8052.0.html,9180.0.html,6727.0.html

Filed under
Click thumbs up if you thought this blog post was useful (login to vote or to comment)


Apart from all the technical details and difficulties, for us having Households as a separate entity is a MUST in our market. We need to be able to follow the history of individuals whilst households do transactions with our customers. It is one of the vital strengths of CiviCRM, and we have helped created something like it in another ERP system in the past for the housing corporation market.
So I would add to the benefits of using households a weird one: it matches the way we look at individuals and the relations between individuals in real life?
From a data management point of view, some of the data we collect 'belongs' to individuals: things like name, birth date, gender. Some things we collect 'belong' to households, things like address, relations between the individuals and some financial stuff as sometimes contracts are entered as a household. You could also argue that the house phone in the living room belongs to the household, whereas the mobile in your pocket is individual data. In our house we have a family emailaddress (belonging to household) and individual stated, the distinction reflects life?


Hi Erik,

I'm really keen to hear more about how you use households as I think you've been quite successful with them. I believe you have every individual associated with a household - how do you manage that? And how do you manage the hooking up & breaking up side of households.

Sounds like I could be in Oprah Winfrey : how do I manage the hooking up and breaking up of households :-) I only have one personal experience and I would like to keep it at that, thank you very much :-)

It is actually quite important to be able to follow individuals throughout household history. For example, if an individual contributes in a major way to the acitivities in the area (organizes a soccer tournament?) and then divorces and remarries, we want to still be able to see what happened. So in an example:
we have a family that we have contact with. As a household they are known as the family Jansen. In CiviCRM, the household Jansen is entered with an address and phone.
The family consists of these individuals that we know of:
Hans Jansen
Trudy Jansen-de Vries
Both individuals are entered in CiviCRM, with their individual data. The address of the household is used, which automatically created a relationship 'Member of household". If we know if kids, we might also enter those as a member of the Household.
If Trudy has seen enough of Hans or the other way around, we end the relationship. Also, the data of the household might change. If Trudy then finds a new man and forms a new household, this is entered and the individuals linked. In this way we can always follow the links from individuals to the households they are part of or have been part of, and also the activities and cases they were involved in, either as individuals or as households.
Does this make sense? I will create the example on the demo site, for as long as it lasts. Look for the individual Trudy de Vries

Trudy has already been hatched, matched & dispatched on the sandbox - probably with a visit to Oprah en route. But I get what you are saying and one thing I realise that you do use addresses for households rather than the Trudy & Hans household - so effectively a household is a house rather than a household which means it still exists after the household has disolved into acrimonious dispute whereas the Trudy & Hans household would need deleting. In this context soft crediting to the household wouldn't make sense.

This also solves the problem of organisations that want to track address histories (which we have previously managed through hooks & multiple custom fields) so it's interesting from that point of view too.

How do you handle people using front end forms? (contribute / event etc)

We do not use contributions in our project, events and activities are kept on the individuals, unless there is a specific household case. And the household always stays, even if it is not active, for historic overviews and reporting.

At the risk of writing before fully thinking it through, the idea of having the 'address' as a contact appeals to me though i expect the logic will fall over as i think it through.
I.e. the idea of saying John lives at house A, Mary lives at House B, then John and Mary hitch and move to House C, before splitting and moving to houses D and E makes a lot of sense. Especially when we are trying to deal with Walklists and with Voter files.
Even the recently (for us) raised issue of wanting to verify each address against a list of all known addresses (so we can use autofill) would work well if the 'address' was effectively a 'contact', and John living at House A was some for of 'locational relationship', with start and end dates being possible.


This is definitely the way we have looked at approaching Households in the past, for purposes such as those you refer to - as the address doesn't attend events, subscribe to a newsletter or contribute, but the people who live there may.

If you get a joint subscription, contribution, membership then generally that would be linked to the relevant "real people" ie Individuals, rather than the Household.

It may just be that I am a lawyer and therefore like ensuring that things like donations and memberships apply to "real people" (or organisations that are given the status of "people" at law), rather than to an amorphous thing we know as a household (but which can be made more concrete by pinning it to an address).

For electoral purposes it is quite important to have this notion of a Household as an address, which will sit within an electorate, distinct from legal entities such as Individuals and Organisations.


Hi Andrew - thanks for sharing your thoughts - i think this may prove to be purely academic as i think it will be a big leap for the schema but, essentially, the way I was thinking was that if an address/location is another Contact Type, then Individuals and Organisations would have a link/relationship to the Address/Location record. When someone moves, the Location Relationship changes, and just as with the existing Relationship approach, you would have a record of previous Locations (though not on the Relationships Tab necessarily - though maybe why not - it would just be current Location Relationship that would need to be exposed on the Summary Screen.

It would definitely be good to have start and end dates for locations for a contact and for "Job Titles" (or Roles and not just the "Employee of" relationship).



I am with Erik on this subject. For my clients ( religious congregations) use of households is essential. This is how the staff thinks about their membership in real life. The system should match the outlook of the end-user. I have dealt with the limitations regarding households by creating custom mail merge tokens to handle joint greetings based on the relationship table. ( See

The financial issues are trickier. I instruct my clients to record contributions against the individual contact in all cases. ( Even though their natural instinct is to put it against the household ) My reasoning for this is that way staff-entered contributions show up exactly the same way as online contributions. Then they run the report "Donation Summary Report (Household)" to put everything in context.

Some of the other issues/headaches: When someone joins as a member, no household is created. There is no method to ask about family members in a front-end profile. I have gotten around this using hooks, however the organization gives up the control of being able to design their front-end profiles as they wish. With the hooks approach, if they need an additional field for their kid they have to ask me to change the hook. Since many organizations like to design their own fill-out forms, this gets to be a hassle.

Another area: When a person is signing up for an event, there is no simple way to say "I am bringing my family" or presenting a list of family members for them to pick from. They have to fill-out a profile/extra screen for each family member. ( Again, I could get around this using hooks, but if each org wants to design their own profiles, its not a flexible solution. )

About divorcing households: if a couple that is part of a household splits up, the staff marks the relationship as disabled. They want to track that the couple was previously married, so they know not to seat them at the same table at an event.

Your idea of automatically treating all people at the same street address as one financial unit/household will not work in many situations. For example, many young adults share apartments with 1 or more friends because they cannot afford to live alone. In those cases, each roommate gets their own mail and is not treated as a household. In other cases, a nuclear family ( eg 2 parents with their 3 kids) share their home with the grandparents. The grandparents are treated as one household, the nuclear family is treated as a different household.

In the situation where 2 adults who are living together for romantic reasons, sometimes they are treated as a household, sometimes not. It really depends on the couple and their stated preferences to the organization.

It depends if there are children in the household or not.

If its just 2 adults, the household record is left in place, however the "household member of" relationship is either disabled or marked with an end date for both adults.

If its 2 adults plus kids, the household record is left in place. The adult who has the kids still living with them would remain a active "household member of" that household. For the adult who has moved out, the "household member of" relationship is either disabled or marked with an end-date.

If the children are bouncing back and forth, 50% time at each parent's home then the child is marked as a "household member of" both households.

For sending postal mail/email communication related to the kids ( such as inviting the parents to a school event ), then we look at the "parent of" and "step-parent of" relationship.

Good post Eileen. Couple things --

You can still create a new household "on the fly" when working in an individual record. When you choose to share a household and enter the name of the household, if there is no match Civi recognizes it as a new household. It then exposes the address fields which are inserted into the household record. I think v3.0 that was handled with a modal popup -- it's now done inline.

Re: where data is stored -- what I tell clients across the board with all contact type handling is to attach the related record to the entity that owns it. In other words -- don't overthink. If John Doe is donating and receives a match donation through his company, I would attach the contribution to his record. If the donation clearly comes from him and his wife, I attach to the household record.

Piggy-backing on Erik's last comments -- I think what we ideally would want, but may be tricky to spec such that it doesn't annoy people who don't want it -- is to be able to see some of the related contact sub-records. When I get into John Doe's record, I'd like to see if the Doe Family has made any contributions. And if in the Doe Family record, I'd like to see if John and Jane have records attached independently.

Your comment about using soft credits is viable, but the biggest problem I have is that it requires the user to manually remember that connection. I think the soft credit data model is perfect -- Doe Family has the contribution and John Doe has a soft credit. But if I've already built the household relationship, my expectation is that the "related sub-records" action will happen automatically. I should need to remember, every time I log a contribution, that John is related to Doe Family or to Jane or whatever.

My vote would be to have the ability to turn on/off the "related record" feature, as many orgs would not want it present. If turned on, I would make it universal -- John can see related records for ANY of his relationships (maybe in expandable panels). Or in the settings to choose which relationships will act this way. Households is the obvious one, but there's value in seeing my employer's related records as well, my spouses, and various other relationships.

On your last point about exporting records -- just a note that v3.2 adds the option to merge households on export (previously only available when doing mailing labels). So that helps improve the household function. And the use of the postal greeting and addressee fields provides a place to control how you would greet and mail to households (Doe Family vs. John and Jane Doe, etc.).

Hi Brian

The add new contact data you described differs to what we saw on the sandbox when I was writing this - can you check the sandbox & see if it does work how you say?

BTW - based on Chapter 2 I was expecting you to come out against households

I agree, that would be great, to be able to see 'through' the layer into the next one - for example activities of the household when looking at the individual and the other way around. If I look at my project though, that is way past their abstraction level at the moment. Just managing activities and events like CiviCRM can do now is already amazing and wonderful to them.
I will have a think how this could be made into a spec :-)

Some scattered background comments, not always very specific in their relevance. Perhaps after thinking about this more and reviewing other materials eg 3.3 specs, I'll try to provide more action-oriented, forward directed recommendations. It won't be for at least another 10 days, however.

1) For political and charitable purposes in Canada all payments have to be from a legal entity: a person or corporation (either for profit or non-profit). Household cannot be used for this purpose. However, for fundraising and development, it is very useful to know about total household contributions as the total amount given is coordinated between spouses. For my Canadian clients and the few American ones I have, contributions are never directly from a household even if it is a joint bank account - the money is attributed to one or more individuals or organizations.

2) Households are great in theory for keeping address and phone data clean for related people through the update process. This convenience tends to break down in the real world of certain demographics - eg younger cohabiting activists tending to sign petitions, and some households with two high professional incomes. And the question is how do you want to be wrong - sending stuff with both names to the new address after a breakup, or to one name at old and new addresses?

3) The process for importing households as well as individual contacts is more time consuming and thus costly. And if the proportion of address/phone changes that involve a change in household membership/definition is significant, the on-going convenience of updating both (or all) addresses with a single edit is reduced, as the effort of breaking up a household is significantly more than twice the effort of a single edit.

4) With the ability to track relationships separately from shared address, an address change for one person could result in triggering a workflow to call to confirm address change for others in domestic relationships with that person.

5) For many non-profit, advocacy, and membership organizations, the kinds of interactions and relationships that are important are more easily handled through using individuals rather than households as the base unit. This is particularly the case when postal mailing costs can be brought down by consolidating residents at a single address into a single postal mailing label, and development and fundraising targeting can be done using relationships / soft targetting (at least in theory). It doesn't work as well for others, eg ones with free family memberships for those cohabiting with a full member, though even here it can be implemented through relationships rather than creating Household contacts.

6) Committed, stable, financially interdependent (from a fundraising perspective) relationships occasionally involve more than one address usually due to jobs in different cities. About 1 in 2 marriages in Canada end in divorce, and I think the figure may be higher for common law relationships which are considered legal marriages after 12 months. Joint custody of kids is common, with kids alternating week by week between parents. Even when one parent is granted custody, it is common for the other spouse (usually the father in heterosexual couples) to get the kids every other weekend or more.

7) For organizations tracking contacts with whom they do not have strong aand deep relationships, e.g. petition-signers, occasional event-attendeees, people who are door-knocked on every couple of years, my sense is that it is safer to treat address and home phone information as varying by individual rather than by household. Checking on household status when updating an address or phone number is awkward and not always effectively included in the business rules of organizations. When the organization has relatively intense interactions and deeper knowledge of the relationships, eg religious community members, a housing coop with fairly accurate and up to date knowledge of who is living in and financially responsible for its units, then it might be safer to assume to assume that household records will be accurately terminated.

8) Somewhat unrelated, Canadian election authorities, possibly in cahoots with Canada Post, seem to be assigning addresses location codes. For certain targetting purposes, it is highly relevant what the address is irrespective of the current occupant. The new occupant of a home is more likely than average to share the same political, consumer, and charitable giving propensities of the former occupant. In a way, an address with a history behind it is a like a tiny census track. This is much more relevant to political organizations and campaigns that deal with almost all residential addresses than it is to organizations that are much more targetted.

Thanks for your thoughts Joe. The comments on this blog have been really great - some excellent points made.

I'll check back in case you do formulate your thoughts more.

On the migration - I got on pretty well with our trial report using CiviMigrate (3 steps create household, create individual & include household id as shared address id, create relationship) . I did have to put a few lines in a hook to set the household name.

Anonymous (not verified)
2010-09-01 - 19:21

Thanks for the write-up.

I need help/clarification on one of your problem areas: How you ensure a family only receives one copy of a snail mail and that it is appropriately addressed?

You say this has been mostly solved - how? I don't know how to handle it efficiently.

Update: today is a day of learning and eating my words - I see now that the Merge contacts in the mailing label export can solve many of my problems. But - I have to add Addressee info to all of my contacts to make it work, because most of them were created in previous versions of CiviCRM that didn't have the Addressee field, so they are blank. It took awhile for me to figure out that is what the problem was.

Oh cool - I was thinking I needed to reply but my reply wouldn't have helped as I hadn't thought of that