Sign Up for Our Free Webinar + Best Practices for Handling Constituent Deletion


Our free webinar on using the charts available on the Performance Overview in ResultsPlus will be held December 8th at 1PM Central Time. If you would like to learn more about it please register today!

Best Practices for Handling Constituent Deletion

It happens from time to time. You have a constituent, or a group of constituents, that you think you may want to remove from your database. As you think about this, a common question may come to mind:  Do I really want to remove these records from my database, or should I just deactivate them? The answer to that question is the ever-popular, “It depends.”

And these are the things on which it depends: Is the constituent a donor? If yes, consider marking them deceased (if the person has passed away) and inactive rather than deleting them from your database. There are a couple reasons for this.

  • You do not want to lose this donor’s giving history, and it will be deleted along with the rest of this person’s information if you delete the record.
  • Other donors may wish to make donations in memory of this person. Do you know any family members of this person? Close friends? Perhaps a conversation with these folks will inform you regarding interest in memorials.

If the constituent is not a donor, is there other valuable information you do not wish to lose? Known relationships to other donors, long-time volunteer, potential donor, etc. Again, if the answer to this question is yes, you may be best served by marking the record inactive.

If the record is not that of a donor, tribute, viable prospect, or other “asset”, consider deleting the record. A good example of a candidate for deletion is a record that was added to your database because of a rented or purchased direct mail list. Often, there are time limits for using these lists. If the time has passed, identifying all the non-donors from the list can be done with a query. I like to use specific Source codes when I initially import the list. I can then use that code as part of my query to identify those I wish to delete. The query can be used to simply delete the entire group of records.

Not every candidate for deletion comes from an easily identifiable list. This is where the rubber meets the road (or where policy meets reality, if you prefer). Implementing a maintenance policy at your organization needn’t be too time-consuming and can help handle the ongoing need to ensure you do not have “excess baggage” in your database. I recommend creating a group in your database called “Potential Deletes.” This group can then be accessed by everyone who uses ResultsPlus. As people identify records they feel are candidates for deletion, they can add the records to the group. Then, at the end of the month (or quarter), have a quick meeting to review the candidates to decide which ones should be deleted and which ones shouldn’t. Remove any records from the group that got in there erroneously, based on the outcome of the meeting. Then, use the group to delete the remaining records. Afterward, you’re ready to move ahead with a group that will slowly gather candidates again over the coming months.

One note: Remember that you can merge records, too! Perhaps the record is a duplicate and should be merged into another record instead of deleted. That’s OK, too. The outcome is the same: happy data!

Are there other ongoing data concerns that crop up in your database? Feel free to share them by submitting a comment below, and I’ll try to address them in an upcoming post.