Wednesday, October 15, 2014 - 13:17
Written by

When generating mailing labels, CiviCRM users have the option of choosing the address to be used (e.g. you can select "Primary," "Home" or "Work") depending on where you want to reach your contacts.

CiviMail, however, does not provide this option. Instead, CiviMail automatically chooses the address for each contact - a process we can only control on a contact-by-contact basis by setting the "Bulk Mail" or "Primary" flags for each individual contact.

For many of us, the ability to only send to home or work email addresses has not been important because email addresses transcend location: we check our work email at home and our home email at work and have all made individual choices about which ones we are going to use regularly and which ones we selectively check.

However, there are use cases when choosing the right location is critical. At the Progressive Technology Project (PTP), one such use case arose in our work with the Vermont State Employees Association (VSEA). As a union, they have very strict rules about what kind of communication they can send to a worker's official work address and what kind of communication really needs to go the home address.

The inability to control this communication made it impossible to use CiviMail, despite having transferred every other aspect of their database to PowerBase (PTP's implementation of CiviCRM).

In response, PTP began investigating how to provide this functionality. Our first effort went into design an extension. We developed and rejected various designs:

  • Ability to assign all addresses of a given location to bulk mail prior to sending out the message. Then, remove all bulk mail designations to allow "normal" sending of email. This method was rejected because it's clumsy, prevents the real use of the bulk mail flag, and requires complicated combining of groups to prevent email messages from being sent to a given location (i.e. if you only want messages sent to home addresses, you still have to ensure that nobody with just a work address is included in the mailing).
  • Swap out email addresses using the hook_civicrm_alterMailParams. This method could allow us to check to ensure the right email address is chosen just before it's sent. This method was rejected because it's resource intensive. In addition to doing a lookup on each email sent, it would require updating the database to fix the table storing the record of which email address was used.

At this point, we began investigating the core code more closely and realized that we could make the change in core with only minimal modifications to the code.

And thus this feature was born:

It's been assigned to a CiviCRM version far far into the future (4.7), however, we're currently using it with 4.4 and it should apply relatively easily to any version in between.

If people have suggestions on how to implement this feature in a better way, please let us know. And if you'd like to see this feature go into an earlier version of CiviCRM, please comment on the ticket.

Filed under


Jamie - Thanks for coming up with both the requirement AND the implementation. This will be part of the 4.6 release.

nice work batman

extra karma for addition of a unit test!


Looks like a nice implementation.

Great feature, it will be widely adopted.  Thanks for sharing.

Thanks for this features. I think it could be useful to extend this idea to postal mailing also. For example, you could choose whether you want to send postal to personal address, professional one or just primary one.

Yes, this is important for us for both bulk mail and printed addresses.

An important missing feature!  Please push it to an earlier release.  We could use this immediately.


The reason why we don't use CiviMail is exactly because you cannot specify the location.

Thank you Jamie for adding this missing feature!

This is a feature that we are begging for. It allows us to specify a named contact for an organisation AND be able to contact them through an independent e-mail address.

The only thing that would stop me using it would be if we could force a 1:1 relationship with an individuals account.