Answers.Body: <p>CiviCRM has a "trash" feature which flags contact records as trash without actually deleting them. Contacts with the flag set to 1 are excluded from most reports, etc.</p>
  
  <p>Their contributions, etc., will not be deleted but may be hidden from reports and interfaces as well. That may or may not be what you want. If you wish to see all the contributions, I don't think there is anything you can do without writing code to deal with most interfaces, but a lot of the reports have a filter to show/hide contributions from trashed contacts.</p>
  
  <p>You can toggle this feature under <a href="http://dmaster.demo.civicrm.org/civicrm/admin/setting/misc?reset=1">Administer > System Settings > Misc</a>, and there's a CMS-level permission "CiviCRM: access deleted contacts" that controls which users can see trashed contacts.</p>
  
  <p>All said, I'm not sure that deleting or trashing contacts is the appropriate solution. It seems rather drastic to delete contacts for the purposes of returning manageable result sets. A better solution might be to hire a <a href="https://civicrm.org/partners-contributors">CiviCRM partner</a> to build a custom search interface that better suits your needs. Or, a low-cost approach that occurs to me is to use your advanced-search know-how to build a Smart Group of current contacts as defined by you, then train collaborators to run their searches within this group.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-23T19:51:12.050Z
Answers.Text: Seconded for the last paragraph!
Answers.UserDisplayName: Allen Hutchison
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-23T19:21:58.627Z
Answers.LastActivityDate: 2016-08-23T19:21:58.627Z
Answers.UserDisplayName: universalhandle
Answers.Body: <p>I have an extension called <a href="https://github.com/MegaphoneJon/com.dpci.constituentsonly" rel="nofollow noreferrer">Constituents Only</a> that provides this functionality.  It repurposes the "Do Not Trade" checkbox as an "Exclude from Search" checkbox.  Non-searchable contacts are primarily accessible via the relationships tab to other contacts.</p>
  
  <p>I have a version 2.0 (which I haven't found time to make public yet) that will return the related contact when searching - that is, if "Jane Doe" is searchable and her spouse "John Doe" is not, searching for "John" will return <code>Jane Doe (John Doe)</code>.  It also adds a checkbox to Advanced Search to search unsearchable contacts.  However, this isn't quite what you're asking for, and version 1.0 is.  I hope to release a new version at some point which toggles the behavior between the 1.0 and 2.0 versions, but incorporates newer features like the "search unsearchable contacts" checkbox.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-28T05:23:03.090Z
Answers.Text: Did v2 ever progress to a shareable concept Jon?
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-07-17T21:18:23.773Z
Answers.Text: LOL just found my way back to this post again. Guess I should just take v1 for a run :-)
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-02-14T17:26:50.917Z
Answers.LastActivityDate: 2019-02-14T17:26:50.917Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>You could create a custom field for all contacts called "Status" with options of Active and Archived. That will give you the selection you need in most places to easily include / exclude the appropriate contacts, especially on many reports and Advanced Searches. Then create two smart groups - Active and Archived - which include the appropriate contacts, and that will make the selection easier in most other places. Depending on the size of the database, how often you are rebuilding the smart group cache, and your host, you could take a hit on performance, so you have to use your judgement there.</p>
  
  <p>This isn't transparent to users, but at least it's easily understood and it's simple - if they are Archived, check the field on the contact record. This gives you the flexibility of including the Archived contacts' contributions, event attendances, etc, when you want to compare numbers across years, but excluding them easily when creating current communications, etc.</p>
  
  <p>The other thing I like about this is that it makes keeping the database up to date everyone's responsibility in real time on a going forward basis. There are going to be even basic users who learn of a contact that leaves an organization, or moves away, etc. This gives them the ability (and hopefully the responsibility) to mark that contact as Archived in the database as soon as they get the information, instead of waiting to tell someone, or for it to be caught the next time six months from now when someone goes through the database to find the Archived contacts.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-25T12:26:27.040Z
Answers.LastActivityDate: 2016-08-25T15:59:35.150Z
Answers.LastEditDate: 2016-08-25T15:59:35.150Z
Answers.UserDisplayName: guyiac
Answers.Body: <p>Here's a kind of wacky idea that might work for you: modify the contact type field in the civicrm_contact table to allow a new 'Archived' value in the enum list. Then run an occasional cron that converts Individual contact types to Archived contact types if they're "old" by whatever criteria you have. CiviCRM will ignore these contact records pretty much in every normal search/report. Or it might break something ... best to try this out on a test copy first. You'll still be able to access information in these records, using views, for example, if you're using Drupal.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-07T15:57:25.347Z
Answers.LastActivityDate: 2016-09-07T15:57:25.347Z
Answers.UserDisplayName: Alan Dixon
Answers.Body: <p>Or you can also create a Report filtered on not-old contacts (as a Smart Group, for instance)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-30T20:14:46.207Z
Answers.LastActivityDate: 2016-08-30T20:14:46.207Z
Answers.UserDisplayName: Jacques-Marie Moranne
Body: <p>Deleting contacts causes problems because it removes their contribution records. </p>
  
  <p>At the same time we don't want old contacts to show up unless they are explicitly requested (such as when searching for deleted contacts). </p>
  
  <p><strong>Is there any way to hide old contacts and exclude them from all queries?</strong> I know how to do this with advanced searches, but I don't want my basic user to have to deal with this.</p>
  
  <p>Are there other ways to deal with old contacts and keep the database from becoming bloated?</p>
  
  <p>I appreciate any help.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-30T20:08:54.087Z
Comments.Text: There are some good answers so far. Fleshing out the scenario might help people come up with advice. You could give some concrete examples of the searches you are doing, and what old contacts are in this instances, and why they are annoying, etc.
Comments.UserDisplayName: michaelmcandrew
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-09-07T16:06:06.907Z
Comments.Text: +1 on this - there are a wide variety of circumstances in which having an "inactive" flag would be helpful, separate from "is_deceased" or "deleted" but acting similarly to one or the other.  Especially for folks coming from Raiser's Edge, where "constituents" are your donors - but donor's spouses, bosses, etc. might be in your database, but you don't want to explicitly track them.  There are plenty of scenarios, and gnarly smart-group approaches aren't a great solution!
Comments.UserDisplayName: Jon G - Megaphone Tech
Tags: <contacts><core>
Title: How to hide old contacts from default search? (best practices for old contacts)
ThreadText: # How to hide old contacts from default search? (best practices for old contacts)
  
  (Asked by: username_0 on 2016-08-23)
  
  Deleting contacts causes problems because it removes their contribution records.
  
  At the same time we don't want old contacts to show up unless they are explicitly requested (such as when searching for deleted contacts).
  
  **Is there any way to hide old contacts and exclude them from all queries?** I know how to do this with advanced searches, but I don't want my basic user to have to deal with this.
  
  Are there other ways to deal with old contacts and keep the database from becoming bloated?
  
  I appreciate any help.
  
  **Tags:** contacts, core
  
  > **Comments:**
  > **username_1**: There are some good answers so far. Fleshing out the scenario might help people come up with advice. You could give some concrete examples of the searches you are doing, and what old contacts are in this instances, and why they are annoying, etc.  
  > **username_2**: +1 on this - there are a wide variety of circumstances in which having an "inactive" flag would be helpful, separate from "is_deceased" or "deleted" but acting similarly to one or the other.  Especially for folks coming from Raiser's Edge, where "constituents" are your donors - but donor's spouses, bosses, etc. might be in your database, but you don't want to explicitly track them.  There are plenty of scenarios, and gnarly smart-group approaches aren't a great solution!  
  
  ---
  
  ## 5 answers
  
  ### Answer by username_3 on 2016-08-23. Score: 6
  
  CiviCRM has a "trash" feature which flags contact records as trash without actually deleting them. Contacts with the flag set to 1 are excluded from most reports, etc.
  
  Their contributions, etc., will not be deleted but may be hidden from reports and interfaces as well. That may or may not be what you want. If you wish to see all the contributions, I don't think there is anything you can do without writing code to deal with most interfaces, but a lot of the reports have a filter to show/hide contributions from trashed contacts.
  
  You can toggle this feature under [Administer > System Settings > Misc](http://dmaster.demo.civicrm.org/civicrm/admin/setting/misc?reset=1), and there's a CMS-level permission "CiviCRM: access deleted contacts" that controls which users can see trashed contacts.
  
  All said, I'm not sure that deleting or trashing contacts is the appropriate solution. It seems rather drastic to delete contacts for the purposes of returning manageable result sets. A better solution might be to hire a [CiviCRM partner](https://civicrm.org/partners-contributors) to build a custom search interface that better suits your needs. Or, a low-cost approach that occurs to me is to use your advanced-search know-how to build a Smart Group of current contacts as defined by you, then train collaborators to run their searches within this group.
  
  > **Comments:**
  > **username_4**: Seconded for the last paragraph!  
  
  ---
  
  ### Answer by username_2 on 2019-02-14. Score: 3
  
  I have an extension called [Constituents Only](https://github.com/MegaphoneJon/com.dpci.constituentsonly) that provides this functionality. It repurposes the "Do Not Trade" checkbox as an "Exclude from Search" checkbox. Non-searchable contacts are primarily accessible via the relationships tab to other contacts.
  
  I have a version 2.0 (which I haven't found time to make public yet) that will return the related contact when searching - that is, if "Jane Doe" is searchable and her spouse "John Doe" is not, searching for "John" will return `Jane Doe (John Doe)`. It also adds a checkbox to Advanced Search to search unsearchable contacts. However, this isn't quite what you're asking for, and version 1.0 is. I hope to release a new version at some point which toggles the behavior between the 1.0 and 2.0 versions, but incorporates newer features like the "search unsearchable contacts" checkbox.
  
  > **Comments:**
  > **username_5**: Did v2 ever progress to a shareable concept Jon?  
  > **username_5**: LOL just found my way back to this post again. Guess I should just take v1 for a run :-)  
  
  ---
  
  ### Answer by username_6 on 2016-08-25. Score: 3
  
  You could create a custom field for all contacts called "Status" with options of Active and Archived. That will give you the selection you need in most places to easily include / exclude the appropriate contacts, especially on many reports and Advanced Searches. Then create two smart groups - Active and Archived - which include the appropriate contacts, and that will make the selection easier in most other places. Depending on the size of the database, how often you are rebuilding the smart group cache, and your host, you could take a hit on performance, so you have to use your judgement there.
  
  This isn't transparent to users, but at least it's easily understood and it's simple - if they are Archived, check the field on the contact record. This gives you the flexibility of including the Archived contacts' contributions, event attendances, etc, when you want to compare numbers across years, but excluding them easily when creating current communications, etc.
  
  The other thing I like about this is that it makes keeping the database up to date everyone's responsibility in real time on a going forward basis. There are going to be even basic users who learn of a contact that leaves an organization, or moves away, etc. This gives them the ability (and hopefully the responsibility) to mark that contact as Archived in the database as soon as they get the information, instead of waiting to tell someone, or for it to be caught the next time six months from now when someone goes through the database to find the Archived contacts.
  
  
  ---
  
  ### Answer by username_7 on 2016-09-07. Score: 1
  
  Here's a kind of wacky idea that might work for you: modify the contact type field in the civicrm\_contact table to allow a new 'Archived' value in the enum list. Then run an occasional cron that converts Individual contact types to Archived contact types if they're "old" by whatever criteria you have. CiviCRM will ignore these contact records pretty much in every normal search/report. Or it might break something ... best to try this out on a test copy first. You'll still be able to access information in these records, using views, for example, if you're using Drupal.
  
  
  ---
  
  ### Answer by username_8 on 2016-08-30. Score: 0
  
  Or you can also create a Report filtered on not-old contacts (as a Smart Group, for instance)
  
  
  ---
  
  