Blackbaud's eTapestry automatically adds a note when records are merged and it contains a text version of the constituent fields from both records - would like something like this.
I ran a list in Database view and was checking to see if records from a recent constituent attribute needed to be marked active. It showed a group of records that were marked inactive. As I began to mark them active and update, I realized that these were records marked inactive by NXT after merging duplicates. A note indicating that it was marked Inactive by the system after a duplicate merge with Constituent ID, would have helped me identify these right away.
Yes please! When I merge records through merge-o-matic it automatically provides a note which tells me who made the merge, and what was on the original record. It's incredibly useful to be able to have access to both of those pieces of information, so you can follow back up with users if there is a merge problem, and then fix the problem yourself.
Ron - Audit trail sounds great. Primary goal (for me, at least) is for there not to be nothing if the person merging didn't take the time to make any helpful notes about the merge. Speaking from past experience, where the merge might have been days, weeks or months in the past, so the dup is long gone. Thanks!
Kristen - Working through a few more thoughts here:
-Let's say a merge occurs; typically the Source record is going to get deleted. In this case, understanding what was on the dupe record could help you recreate it if needed. This speaks to audit trail, IMO.
-If you caught that the merge should not have happened, but you haven't deleted the dupe, what you'd want to do is reverse the merge. This is something a little different and wouldn't necessarily require an audit trail.
Ron - Yes, that would work, as long as it's somewhere a non-admin or someone not very "database savvy" could see it to at least know there had been a merge. And not just for changing after, but in case maybe the records should not have been merged in the first place, some of the info from the merged record can be seen somewhere.
Kristen - I'd replay that as "I'd like a audit trail of the state of the records pre-merge, in case I need to change something after the fact". That sound correct?
I ran a list in Database view and was checking to see if records from a recent constituent attribute needed to be marked active. It showed a group of records that were marked inactive. As I began to mark them active and update, I realized that these were records marked inactive by NXT after merging duplicates. A note indicating that it was marked Inactive by the system after a duplicate merge with Constituent ID, would have helped me identify these right away.
Yes please! When I merge records through merge-o-matic it automatically provides a note which tells me who made the merge, and what was on the original record. It's incredibly useful to be able to have access to both of those pieces of information, so you can follow back up with users if there is a merge problem, and then fix the problem yourself.
Ron - Audit trail sounds great. Primary goal (for me, at least) is for there not to be nothing if the person merging didn't take the time to make any helpful notes about the merge. Speaking from past experience, where the merge might have been days, weeks or months in the past, so the dup is long gone. Thanks!
Kristen - Working through a few more thoughts here:
-Let's say a merge occurs; typically the Source record is going to get deleted. In this case, understanding what was on the dupe record could help you recreate it if needed. This speaks to audit trail, IMO.
-If you caught that the merge should not have happened, but you haven't deleted the dupe, what you'd want to do is reverse the merge. This is something a little different and wouldn't necessarily require an audit trail.
Agree? Additional thoughts?
Ron - Yes, that would work, as long as it's somewhere a non-admin or someone not very "database savvy" could see it to at least know there had been a merge. And not just for changing after, but in case maybe the records should not have been merged in the first place, some of the info from the merged record can be seen somewhere.
Kristen - I'd replay that as "I'd like a audit trail of the state of the records pre-merge, in case I need to change something after the fact". That sound correct?