Answers.Body: <p>I would second Erik's suggestion of adding an "on hold" or "bad address" property to postal mail addresses, similar to what civicrm has for email address. </p>
  
  <p>The "invalid postal address" scenario is common enough, and this has come up a few times, that a generic solution is definitely worth it and avoid orgs that do a fair amount of mailings work around this. I would structure this similar to the "on hold" for email addresses, and then have the mailing label and other workflows respect the property</p>
  
  <p>Integrating this with the USPS (or other providers) address cleanup/validation would make it even better</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-11T14:38:09.773Z
Answers.Text: I know this is a very old question, but it is still relevant. I find this answer, with it's integration into Civi workflows for labels, merges, etc. to be much more useful than the location type solution, which is easy but incomplete. I'd like to see this added to Core as per feature request: https://issues.civicrm.org/jira/browse/CRM-16430
Answers.UserDisplayName: Phil Morice Brubaker
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-01-16T16:38:56.847Z
Answers.Text: Has there been any movement on a feature like this?
Answers.UserDisplayName: J. Rolfs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-20T15:48:35.613Z
Answers.LastActivityDate: 2015-04-30T17:43:20.183Z
Answers.LastEditDate: 2015-04-30T17:43:20.183Z
Answers.UserDisplayName: Donald Lobo
Answers.Body: <p>I guess I would add an 'on hold' custom field to the Address entity?</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-20T08:10:53.133Z
Answers.LastActivityDate: 2015-04-20T08:10:53.133Z
Answers.UserDisplayName: ErikH - CiviCooP
Answers.Body: <p>RE: Lobo's answer.  We've (Palante) written an extension that adds a Fundraising address flag, based on the Primary address flag, which could be repurposed for this.  Though without knowing all the use cases, I can think there might be differences, one of which is you can't have more than one fundraising address but you might have more than one bad address.  We'll be adding this extension to the forthcoming experimental extension list, so it will be available soon.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-28T15:01:45.697Z
Answers.LastActivityDate: 2015-04-28T15:01:45.697Z
Answers.UserDisplayName: Joseph Lacey
Answers.Body: <p>The approach I would take is as follows:</p>
  
  <p>Firstly  I would create a group for contacts where mail to the postal address has been returned as undeliverable for one reason or another.</p>
  
  <p>When mail gets returned the contact gets added to the group. The group can then be excluded form further mailing attempts to reduce your mailing costs.</p>
  
  <p>You can then focus on contacting the person or organisation involved via other channels (phone, email) to get a correct address from them.</p>
  
  <p>When you have a correct address you can edit their record and remove them from the group so that they then get included in future mailings.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-20T12:53:24.277Z
Answers.Text: I would caution against using groups for this purpose because (1) if a contact has multiple addresses, data is not captured about which address is invalid, and (2) if the contact does something like make an online donation, their new (presumably valid) address will be captured but they will continue to be excluded from mailings.
Answers.UserDisplayName: Sean
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-20T11:28:55.333Z
Answers.LastActivityDate: 2015-04-21T13:46:43.193Z
Answers.LastEditDate: 2015-04-21T13:46:43.193Z
Answers.UserDisplayName: Graham
Answers.Body: <p>I think a location type of something like "Rejected" will give you great flexibility. If you want to get a bit more elaborate, combine the location type with a custom field that tracks the <a href="http://pe.usps.com/text/dmm300/507.htm">reason for nondelivery</a>.</p>
  
  <p>By using a location type, it simplifies searching, exporting, and importing when you want to run those addresses through NCOA or have a user work through a spreadsheet of bad addresses. When good ones are found and it's time to import, use the <a href="https://civicrm.org/extensions/api-csv-import-gui">API csv Import GUI extension</a> so that you can overwrite the address records, change their location type, and wipe the custom field in one pass.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-02T20:43:39.533Z
Answers.Text: Agree. We have often done this, eg a Location Type of GNA = Gone No Address
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-20T12:52:22.787Z
Answers.LastActivityDate: 2015-04-20T12:52:22.787Z
Answers.UserDisplayName: Nicholai
Body: <p>I work with a number of organizations that do a lot of outreach via postal mail. What is the best way to handle the bad addresses when returned mail is received? I do not want to simply delete the address as there may be a need to easily reference it in the future (for NCOA updates or to avoid re-adding it from another source).</p>
  
  <p>There doesn't seem to be a way to simply mark an address as bad or inactive like the On Hold field for emails. One idea I had would be to just use a new Address Location Type but I'm wondering if there are other approaches.</p>
  
Tags: <4.6.0><contacts><addresses>
Title: What are best practices for bad postal addresses?
ThreadText: # What are best practices for bad postal addresses?
  
  (Asked by: username_0 on 2015-04-20)
  
  I work with a number of organizations that do a lot of outreach via postal mail. What is the best way to handle the bad addresses when returned mail is received? I do not want to simply delete the address as there may be a need to easily reference it in the future (for NCOA updates or to avoid re-adding it from another source).
  
  There doesn't seem to be a way to simply mark an address as bad or inactive like the On Hold field for emails. One idea I had would be to just use a new Address Location Type but I'm wondering if there are other approaches.
  
  **Tags:** 4.6.0, contacts, addresses
  
  
  ---
  
  ## 5 answers
  
  ### Answer by username_8 on 2015-04-20. Score: 9 | Accepted answer
  
  I think a location type of something like "Rejected" will give you great flexibility. If you want to get a bit more elaborate, combine the location type with a custom field that tracks the [reason for nondelivery](http://pe.usps.com/text/dmm300/507.htm).
  
  By using a location type, it simplifies searching, exporting, and importing when you want to run those addresses through NCOA or have a user work through a spreadsheet of bad addresses. When good ones are found and it's time to import, use the [API csv Import GUI extension](https://civicrm.org/extensions/api-csv-import-gui) so that you can overwrite the address records, change their location type, and wipe the custom field in one pass.
  
  > **Comments:**
  > **username_9**: Agree. We have often done this, eg a Location Type of GNA = Gone No Address  
  
  ---
  
  ### Answer by username_1 on 2015-04-20. Score: 5
  
  I would second Erik's suggestion of adding an "on hold" or "bad address" property to postal mail addresses, similar to what civicrm has for email address.
  
  The "invalid postal address" scenario is common enough, and this has come up a few times, that a generic solution is definitely worth it and avoid orgs that do a fair amount of mailings work around this. I would structure this similar to the "on hold" for email addresses, and then have the mailing label and other workflows respect the property
  
  Integrating this with the USPS (or other providers) address cleanup/validation would make it even better
  
  > **Comments:**
  > **username_2**: I know this is a very old question, but it is still relevant. I find this answer, with it's integration into Civi workflows for labels, merges, etc. to be much more useful than the location type solution, which is easy but incomplete. I'd like to see this added to Core as per feature request: https://issues.civicrm.org/jira/browse/CRM-16430  
  > **username_3**: Has there been any movement on a feature like this?  
  
  ---
  
  ### Answer by username_4 on 2015-04-20. Score: 3
  
  I guess I would add an 'on hold' custom field to the Address entity?
  
  
  ---
  
  ### Answer by username_5 on 2015-04-28. Score: 2
  
  RE: Lobo's answer. We've (Palante) written an extension that adds a Fundraising address flag, based on the Primary address flag, which could be repurposed for this. Though without knowing all the use cases, I can think there might be differences, one of which is you can't have more than one fundraising address but you might have more than one bad address. We'll be adding this extension to the forthcoming experimental extension list, so it will be available soon.
  
  
  ---
  
  ### Answer by username_6 on 2015-04-20. Score: 1
  
  The approach I would take is as follows:
  
  Firstly I would create a group for contacts where mail to the postal address has been returned as undeliverable for one reason or another.
  
  When mail gets returned the contact gets added to the group. The group can then be excluded form further mailing attempts to reduce your mailing costs.
  
  You can then focus on contacting the person or organisation involved via other channels (phone, email) to get a correct address from them.
  
  When you have a correct address you can edit their record and remove them from the group so that they then get included in future mailings.
  
  > **Comments:**
  > **username_7**: I would caution against using groups for this purpose because (1) if a contact has multiple addresses, data is not captured about which address is invalid, and (2) if the contact does something like make an online donation, their new (presumably valid) address will be captured but they will continue to be excluded from mailings.  
  
  ---
  
  