Moving Gifts vs Merging Records
We have a lot of spouses with separate records, but they get soft credit for each others gifts and are recognized together for their combined giving. I am trying to streamline this so that pulling information for these spouses isn't so complicated by making one record for spouses that fit this category.
In cases where we have spouse records with no giving, I just copy any actions or other important info over to the head of household spouse record and then break the link and delete the other spouse record leaving only the relationship record on the head of household spouse record. I prefer this method because then I don't have to re-add the spouse as a relationship record.
Now that we have the ability to move gifts, I am thinking that this would be better than merging two spouse records (so that the gifts transfer) and then re-adding the merged spouse as a relationship. I am curious if anyone else has done this and if you ran into any issues.
Comments
-
@Rachael Daniels Welcome to the BB community forums.
I'm not going to ask about why you have the need to remove spouse records with gifts or move actions.
About moving the gifts in webview, it's a one-at-a-time process I believe to ‘move’, so could take some time if you're having to move multiple gifts. You would still need to move any actions like you mentioned or other notes/attributes/addresses, etc.
From those facts alone, merging would seem to be more efficient. I'd need to try both ways to be certain. There are options to merge in webview that might make process faster.
Hard to say without really knowing your database.2 -
@JoAnn Strommen won't ask why you are doing this, but I will. If you are doing this to make reporting easier, then I think there are better ways to accomplish this. These records were created for a purpose, and just a lack of giving isn't enough to necessarily determine if the records should be deleted.
I would look at the constituency of these records and see why they are there to begin with. If they had no purpose to begin with, then it's time to look at your data quality policy. If they have actions, why isn't that enough to keep the record as is?
I would be very careful before deleting data like this.
That said, of the two options, merging is definitely the easier option. You can only move one gift at a time. Moving them would take a tremendous amount of time to complete.
2 -
@Dariel Dixon and @JoAnn Strommen Thank you for your input!
The why is a reasonable question and there are many reasons. Data integrity - SOPs for record creation, data entry, etc. - was non-existent before I arrived. In short - I inherited a mess. The rhyme or reason for past data entry practices is inscrutable and undocumented. My biggest reason for having one record for a couple is that it would ensure better data and relationship management. It would also make these records match our current standard for record creation (one record for a couple unless they specifically give as separate donors and are recognized individually).
In the past, actions would be added to one or the other of the spouse records and almost never to both, even though they were making giving decisions as one entity. Gifts would be entered with no real reason to one or the other and then SC to the other. Basically, you have to dig through 2 records to find the history of one couple. And even now, my fundraisers forget to copy actions or to use only the HoH record as the primary info capture. This is also skewing my reporting on portfolio metrics and other things.
I obviously don't want to delete valuable information, however, due to past data entry practices, I don't want to keep bad/useless information. This is why I was considering not merging, so that I could control the data that is kept. Time is obviously a factor to consider, but in most cases, I'd rather have the best data possible than save a little time.
0 -
Thanks for giving us a bit of context. This makes sense. If there has been no data integrity, then you have to do what is necessary to create some sense of order. I would document your new process before deleting. I added the question about constituency to determine what the relationship the constituent had with the organization.
If you are going to try to create a data structure based on the primary constituent (formerly known as HOH), and you are going to move the data from the spouse to the primary constituent, I would make sure that there are no other ramifications to this decision. This would effect data entry as we would no longer be necessarily giving credit to the signer of the check, but to the primary constituent, regardless of signature. This also has impact on email communications to spousal emails. It's quite involved. Make sure you have all of the impacted stakeholders in alignment to make sure all parties are in agreement about this proposed change. This includes retraining fundraisers on entering actions. And possibly putting in safeguards elsewhere. This is a substantial task without question, but it can be done.
@Rachael Daniels, I'm about as big of a proponent as you'll find around these parts, but I think that in these cases, merging the information is the best way to go. Even after the merges, you'll have quite a bit of data cleanup to do. Also, make sure your documentation states how to handle 2 constituent households, as there will always be a number of these.
My organization has a household based data structure. We have done extensive training with people to look for HOH, and even have solicit codes for non-HOH constituents to warn not to enter gifts or actions. It does sound like this is a bit of an organization and cultural shift for you. I hope it goes well.
4 -
@Dariel Dixon I would love to know more about your policies for your household based data structure. One thing you mentioned was the change in email communication, which has been a concern since switching to NXT and using the email marketing tool. Not being able to include relationship records (or emails really) in a mailing list has caused some issues with sending emails to companies and our contacts at the company. This is obviously an issue with spouses who don't have their own record either.
I'm not opposed to having individual records for each spouse (which would solve this problem), but as you correctly recognized, I am working against a big cultural shift in just creating basic SOPs for entering actions and opportunities, let alone when it involves which record (which spouse or even the company vs foundation record) the action or opportunity should be recorded on. Additionally, I am an office of one managing the database, prospect research, gift entry, reporting, etc for 6 fundraisers. I don't have a ton of time to train them, so any change I make is a slow process. Therefore, I do try to make them minimal and as easy as possible.
0 -
@Rachael Daniels Make your life easier. If the spouse records is actually needed (in most cases, a spouse record is not), make sure they soft credit each other by checking the “Automatically soft credit this individual for gifts” box in the general 2 tab of each spouse. If the spouse record is not necessary and they are linked, go to relationship of the spouse and click the "Break the Link Only" and merge the records. I suggest doing it in Database View. It seems that what you are doing it very labor intensive and unnecessary. I also think that organizations need to make a decision on why spouses should have separate records and stick with it.
0
Categories
- All Categories
- 6 Blackbaud Community Help
- 212 bbcon®
- 1.4K Blackbaud Altru®
- 399 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 1.1K Blackbaud CRM™ and Blackbaud Internet Solutions™
- 15 donorCentrics®
- 360 Blackbaud eTapestry®
- 2.5K Blackbaud Financial Edge NXT®
- 654 Blackbaud Grantmaking™
- 571 Blackbaud Education Management Solutions for Higher Education
- 3.2K Blackbaud Education Management Solutions for K-12 Schools
- 939 Blackbaud Luminate Online® and Blackbaud TeamRaiser®
- 84 JustGiving® from Blackbaud®
- 6.6K Blackbaud Raiser's Edge NXT®
- 3.7K SKY Developer
- 248 ResearchPoint™
- 119 Blackbaud Tuition Management™
- 165 Organizational Best Practices
- 240 Member Lounge (Just for Fun)
- 34 Blackbaud Community Challenges
- 34 PowerUp Challenges
- 3 (Open) PowerUp Challenge: Chat for Blackbaud AI
- 3 (Closed) PowerUp Challenge: Data Health
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Product Update Briefing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports+
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Email Marketing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Gift Management
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Event Management
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Home Page
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Query
- 789 Community News
- 2.9K Jobs Board
- 53 Blackbaud SKY® Reporting Announcements
- 47 Blackbaud CRM Higher Ed Product Advisory Group (HE PAG)
- 19 Blackbaud CRM Product Advisory Group (BBCRM PAG)



