Steps for Duplicate Management in RE NXT, starting in Web View

Austen Brown

As promised in the live Q&A from BB Super Users Session this afternoon... This is my process for merging duplicates in RE NXT. Feel free to comment on this post with any questions you have.

1. Review the duplicates in Web View either through Tools > Data Health > Possible Duplicates or directly from a constituent record.

2. If the constituent is a duplicate, I merge the records in Web View first. --If there is even an inkling that they may not be a match, I cancel here until additional research can be done.

3. After the duplicate is merged, I open up the merged duplicate section of RE NXT: Tools > Data Health > Possible Duplicates > Merged Duplicates tab.

4. Utilizing Database View on a separate screen, I utilize the information listed in the Merged Duplicates tab to locate the two records in DBV.

5. In DBV, I review the two records side-by-side. I pay attention to Consent, Attributes, Ratings, and any other information that only lives within DBV.

6. If information still exists on the duplicate record (the 'source' record), I do another merge only for those areas of a record within DBV.

7. Once the duplicate (source) record is 'empty', I copy/paste the constituent ID into the record that will remain (target record) under Alias with a type of "Merge ID". -- This is to aid in future look-ups, by putting the old ID in the Alias you can search for it within the Advanced Search window.

8. I then save and close the record that will remain (target record).

9. I double-check the duplicate (source) record as 'empty', triple-check that I have the right record open and delete it from the system.

When you are doing this process due to a duplicate created from the conservative matching rate of the Automatic Constituent Matching tool, start in batch and navigate directly to a new constituent's record and click "Merge into another record" button at the top of the window. I will usually do all the constituent review/merges needed prior to approving the gift batch, meaning I complete steps 1-2 repeatedly, and then after the batch is approved, I complete steps 3-9 for any merged duplicates listed.

**This was copied from my 2022 post in the Raiser's Edge Users Group Support Forum on Facebook.

Alex Wong

@Austen Brown
Thank you for posting.

Question: do we have specific information from Blackbaud on what does not merge on webview merging? For example, we do not use Consent, so if that's one of the problem in webview merge. I'm not concern to go into dbview to merge again there.

You also mentioned attribute and rating. However, I think all types of attribute is supported on webivew, at least all the ones I care about: Constituent attribute, Gift attribute. (we do use participant attributes and I know that's not “supported” on webview, so I'm going to test this out).

Would be great if Blackbaud came out directly with details on this. Going to search KB and see.

Austen Brown

@Alex Wong - Unfortunately, I don't know of a KB Article that lays this out - most of my findings are from personal experience. The attributes that don't merge in WV tend to be the inactive ones, same with ratings; consent may or may not merge completely - this is ringing a bell for me as an area that you have do an additional merge in DBV. Let's use this post to share what we run into and create our own documentation!

Kenneth Jimah

@Austen Brown that is quite thorough and like we've all experienced, quite painstaking. I like the idea of adding the deleted Cons ID as an alias.
I really find it puzzling that whilst you can merge Consent in either view by merging Biography, it fails to trigger the Solicit codes hierarchy/exclusivity and a record could end up having both an opt-in and opt-out solicit code.

Alex Wong

@Kenneth Jimah
Solicit Code table is something that every org can configure however you wish, due to that, merging that consolidate them all into the merged record makes sense from a software perspective. (we don't use Consent, so I don't know if that changes anything with Solicit Code values)

Since it's a org-config, having auto-rule that will make org-based decision for you wouldn't make sense, and that's why it needs you to fix record afterward.

Karen Diener

I have no idea how updated this knowledgebase article is, but it is supposed to list the webview data that does not merge when you do a database view merge. It's one that I keep bookmarked.

Alex Wong

@Karen Diener
Thank you, very helpful document.

The document only mention what will not merge if using database view merge. So does that mean webview merge will take care of all and we shouldn't bother with database view merge?

Lee Grisham

@Alex Wong I still think there could be data depending on if you use Events or Volunteer modules that will not be carried over. Webview only seems to take care of “some” of the things that can be managed there.

Have yet to see any Consent fields merged, and because of this and the additional area to store the same information (Solicit Codes, Do no Email/Mail), we don't use it.

Alex Wong

@Lee Grisham
Completely agree, we can “test” all we want but no one has all the modules in RE to really say for sure.

We need someone from Blackbaud to confirm what will and will not merge in webview and dbview. Then based on each org own use of different module can determine if webview or dbview is good enough or must be both.

@Heather McLean @Erik Leaver is this something that either of you can help chase down?

Karen Diener

@Alex Wong:

@Karen Diener
Thank you, very helpful document.

The document only mention what will not merge if using database view merge. So does that mean webview merge will take care of all and we shouldn't bother with database view merge?

I'm pretty sure the best practice is to merge in webview first, and then database view. I don't remember specifics, but know that if you have volunteer or membership information, you would definitely need to do a database view merge too since that has not yet been built out for webview.

This 10 minute video might contain some details, and this 60 minute webinar definitely should have specifics. I know these are both at least a couple of years old, but I'm not sure that too much has changed. The slide deck for the webinar is here: Cleaning your database Spring 2021.pdf

Annette Rurka

@Austen Brown I've been using this procedure since bbcon 2022 and my duplicates are in really great shape. Cleaned up a lot of duplicates at first but now I only have a dozen or so after major imports or DHC processes being run (AddressFinder, PhoneFinder, etc). Thank you for this and your immense help given to BB community.

Andrew Wigley

@Austen Brown
Thank you for your really helpful guidelines. Having recently migrated to RE NXT, we are revising our de-duplication procedures. This knowledgebase article What is the Duplicate Management tool in web view? (blackbaud.com) seems to have further helpful information about what the Duplicate Management tool does and doesn't do, and the differences from the Database View version.

Kevyn Barnes

For folks using Tribute module, I'd add: If tribute acknowledgement has not yet been sent for any tribute gifts on the source record, please make note of which relationship in the constituent record is listed as acknowledgee on each tribute on the source constituent's tribute tab. The tribute acknowledgee name in any merged tributes disappears. This happens regardless of whether you merge tributes in WV or DBV first.

Donella Robb

@Austen Brown Thank you so much for sharing your process last year. One question that has recently come up from our team, is whether there is a more automated way to dedupe RENXT when there is a high match likelihood? We have a large number and merging one at a time is super time consuming. Are you aware of any way to automate where there is a high match likelihood?

Austen Brown

@Donella Robb - I have not, unfortunately. I'll keep this on my radar though and if I hear of anything I'll follow-up here.

Austen Brown

New this week, there are a few improvements to the merge process in WV - this may change some of the later steps, but I'd still test this out and see if any data remains in DBV after the initial merge.