Removing inactive constituents

Julie Gurnon · July 2017

Hello friends,

In my never-ending quest to clean up the database I inherited, I have this question that I am hoping someone can confirm that what I'm thinking of doing is OK.

I want to delete all inactive constituents in the database. The instructions on Knowledgebase say to create a backup in the Blackbaud Management Console on our server. (The software is simply installed on our computers, not hosted by Blackbaud.) I am unable to locate the console they are referring to.

The second step is to create an import file (with Import ID numbers that includes ALL fields) before finally going in the database and doing a global delete.

If we ever need to get those records back, will the import file be enough to do that? In essence I'd be skipping Step 1.

Thanks!

Joshua Bekerman bCLO bCRE · July 2017

How do you define inactive constituents and why do you want to delete them?

JoAnn Strommen · July 2017

I'm guessing you've looked at the 'inactive' records and know that you're not deleting gifts, historical info.... That's a big move - not going to second guess you on that.

I know creating the back up as not as easy as they make it out to be from the frustration I've seen with each of our IT people. It can be done and I would definitely do before any type of global delete. Things happen, computers crash, RE errors....

The file you're creating will just contain the data on the records - should you need to import and/all back into RE. Step 1 creating the back up will ensure you don't lose/damage/corrupt all your records should something happen.

Think the console may only be accessible from admin accounts. I would contact support.

Jen Claudy · July 2017

Orgs I've worked at with a Local Install (not Hosted) have usually restricted the Management Console to IT staff. At one, I was permitted to use it, but I had to do so from an IT workstation. Other times, I've had to provide instructions to IT, who used the Management Console to complete whatever it was that I needed done.

Melissa S Graves · July 2017

I can not imagine ever choosing to delete any large set of records from a database ever - not sure what reason would ever necessitate that. What happens to historical gift reporting, what happens when someone looks someone up and they are not there and therefore assume they are not inactive donors, never gave, no one has ever contacted them or solicited them, etc. It has a lot of pitfalls that I would never entertain.

There can only be one instance of the BMC for any install so it is likely limited to your IT department. These backups are something you should be requesting from IT ANY time you do any large global change, import, etc. Please familiarize yourself with it with regards to your "quest to clean up the database". Been the one to make a simple mistake without asking for such a backup and it is frightening.

Ryan Hyde · July 2017

That's a big move

I'm just gonna second that statement. You're the master of your own database, but please do be super duper cautious about this.

Julie Gurnon · July 2017

Thanks for the feedback, everyone! These records have no information in them except maybe an address (no notes, historical info, anything). They have never given or volunteered with us. I'm not sure why they were even entered in the first place. I think they may have been added during the conversion years ago. I don't foresee anyone looking them up and trying to get in touch with them. Not even sure addresses are accurate. Anyhow, I'll give it some more thought and not do anything crazy.

Julie

Julie Gurnon:

Hello friends,

In my never-ending quest to clean up the database I inherited, I have this question that I am hoping someone can confirm that what I'm thinking of doing is OK.

I want to delete all inactive constituents in the database. The instructions on Knowledgebase say to create a backup in the Blackbaud Management Console on our server. (The software is simply installed on our computers, not hosted by Blackbaud.) I am unable to locate the console they are referring to.

The second step is to create an import file (with Import ID numbers that includes ALL fields) before finally going in the database and doing a global delete.

If we ever need to get those records back, will the import file be enough to do that? In essence I'd be skipping Step 1.

Thanks!

Ryan Hyde · July 2017

Oh! Hahaha. I used to have a whole bunch of mystery records like that. I just straight up deleted them - didn't even bother trying to retain backups. They were added before our RE conversion and would never pull in any query ever because they had no info, so they were just taking up space. I did make sure to thoroughly check that I was in fact dealing with total ghost records with no meaningful data apart from bio1 data though - I'm sure you've taken your time to confirm your target.

So now my vote is, if you can't figure out the backup procedure, just nuke 'em :P

Julie Gurnon · July 2017

Thank you, Ryan!

Stephanie Crawley · August 2017

Hi Julie, Isn't your server set up to do regularly scheduled back-ups of your database? Assuming so, just find out when the next scheduled full database backup is, and then make sure to do your deletes just after that is done. Then you have a valid full back-up pre-deletions. Just make sure to archive that particular back-up, not write over it, for about 90 days. Once you get more than 90 days out, you wouldn't want to restore from back-up anyway, since too much other data would have changed by then. If you are a bigger organization, more than even 15 days is too far back to restore from back-up, unless in a situation like the-building-burned-down-and-our-server-didn't-make-it kind of emergency.

Catherine Burns · August 2017

Julie Gurnon:

Hello friends,

In my never-ending quest to clean up the database I inherited, I have this question that I am hoping someone can confirm that what I'm thinking of doing is OK.

I want to delete all inactive constituents in the database. The instructions on Knowledgebase say to create a backup in the Blackbaud Management Console on our server. (The software is simply installed on our computers, not hosted by Blackbaud.) I am unable to locate the console they are referring to.

The second step is to create an import file (with Import ID numbers that includes ALL fields) before finally going in the database and doing a global delete.

If we ever need to get those records back, will the import file be enough to do that? In essence I'd be skipping Step 1.

Thanks!

Hi Julie, you've had lots of good replies about back ups etc. but I wanted to provide info about the import file. An import file with all fields is not possible unless your data is very simple and includes no one-to-many relationships. Depending on the data and what it contains - multiple addresses, phone, relationships, actions, relationships, notes etc you may need to make multiple import files of the various types with the same query of records to extract all the information should you ever need or want to reimport some or all of these records. The advantage of import files are that the field headers are correct for imports through RE Import.

However, if you have a product like ImportOmatic you may prefer to extract the data from these records via the Export module to reduce the number of actual exports. As long as you understand the export header names and what they relate to you could always map them through ImportOmatic for reimport should it be required.

Julie Gurnon · August 2017

Thanks for the feedback, Catherine!

Christine Cooke 2 · August 2017

Julie Gurnon:

Hello friends,

In my never-ending quest to clean up the database I inherited, I have this question that I am hoping someone can confirm that what I'm thinking of doing is OK.

I want to delete all inactive constituents in the database. The instructions on Knowledgebase say to create a backup in the Blackbaud Management Console on our server. (The software is simply installed on our computers, not hosted by Blackbaud.) I am unable to locate the console they are referring to.

The second step is to create an import file (with Import ID numbers that includes ALL fields) before finally going in the database and doing a global delete.

If we ever need to get those records back, will the import file be enough to do that? In essence I'd be skipping Step 1.

Thanks!

I'm just going to leave this here. It really is in general excellent best practices to consider -- not just in regards to the panic of converting to NXT.

http://www.billconnors.com/media/Raisers Edge NXT Pricing - To Delete or Not Delete Constituents.pdf

Rachel Bailey · August 2017

Julie, I'd recommend creating exports or import files for the constituent records you want to get rid of before you globally delete them, being sure to include the ImportID. If, for whatever reason, these records ALSO have Gift, Action, Note, or other records attached to them, you'll want to export those separately making sure that the ImportID for the Constituent record and associated record are retained. That way if you ever need to enter them back in the database you could import the Constituents first followed by their associate sub-records. We are also a Habitat affiliate and we used to use RE for our partner family selection process. Yeah, crazy, I know. Now that they are moving to Encompass for that process, we have thousands of applicant records that aren't donor prospects so this is the process I'm going to use to delete them from RE and potentially load them into an Access database for historical record keeping.