Hi all, our development team has been managing a lot of duplicates recently as long-time patrons donate online for the first time and do so by creating a duplicate login. Devo's been leaning on me a lot to run the merge utility out of SSMS so they can make sure membership records stay correct, but I was curious if anyone has made the merge process available in a front-end utility? I'm unfortunately on reduced hours with COVID-19 and my hours don't always line up with our devo team's hours, so giving them the ability to process merges themselves would be helpful.
HI Martin. We do all of our merges with the Constituent Merge Utility and have never done them on the back end. We do have a robust merge procedure though in which we use plans for merge preparation. We require all ticket office staff to learn how to prepare merges and they create a plan indicating what two accounts need to merge and any special notes about that merge. Once a staff person is an expert on prepping merges we give them the ability to begin scheduling merges. So we always have some staff trained to prep and others to merge. It works very well for us.
Hi Terry, thank you for your response. What I'm referring to is, after a user has scheduled a merge, they have to wait for the database to run AP_MERGE_CUSTOMER2 which actually merges the constituents. I've been manually executing this process as requested by users so they can more immediately make the changes necessary to the constituent record, but as far as I know there's no way to run that procedure on the front end. Am I missing a utility that already exists?
The standard practice is to have a SQL Agent job that executes the merge constituents procedure automatically on a schedule. For example, if you have a job that runs the Identify Merge process on Sunday and have staff reviewing the duplicates throughout the week, then you could have the actual merging scheduled for Friday or Saturday nights. That provides enough time for staff to review potential duplicates and schedule the merges identified for the week. Other than the initial set up of the jobs, this approach is generally hands off (other than the work of the people reviewing the potential duplicates and scheduling the merges).
If your internal process does not involve any kind of multi-step review (such that a different human might need to review merges someone else already scheduled - possibly not on the same day the merges were scheduled) you could also have the merge process run more frequently, such as nightly -save for the day of the week the "Identify Duplicates" job runs. That way any scheduled merges are processed at the end of each day.
I see Martin. We have that as a scheduled job to run each Monday.
We have a SQL job set up to run 3 nights a week so that there isn't a lot of wait time. It's generally not been an issue at our organization.