You merged two duplicate constituents last month. Today you pull the recipient list for your fall appeal and there it is: the ID of the record you merged away, or the same person showing up twice. It feels like the merge didn’t take. Usually it did. The marketing effort is just working from a list that was built, saved, or exported before the merge happened.
Below are the common reasons a merged ID resurfaces in an Altru marketing effort, how to tell which one you’re dealing with, and what to change so it stops happening.
First, pin down what you’re actually seeing
“Merged IDs in my effort” can mean a few different things, and each has a different cause. Before changing anything, look at one affected person and answer these:
- Does the old record still exist? Search for the old lookup ID. If it opens a live constituent record, the merge either didn’t complete or was never run for that pair. That’s a duplicate problem, not a merge problem.
- Is the old ID showing up in the effort itself, or only in an export file? If it’s only in the exported file, the issue may be in the export definition or in when the file was generated.
- When was the effort’s list built compared to the merge date? This answers most cases on its own.
Cause 1: the effort used a static selection
A static selection is a frozen list of record IDs taken at the moment it was saved. It does not re-check whether those records still exist or have changed. If a static selection was saved before you merged, it can still point at the source record after the merge, or carry both halves of what is now a single constituent.
What to do: For efforts you run more than once, base them on dynamic selections built from a query, so the list is re-evaluated each time. If you need a static snapshot for audit reasons, rebuild it right before you activate the effort, after any merge work is finished.
Cause 2: the effort was activated or exported before the merge
Once a marketing effort is activated, the recipient list is generally treated as fixed so that responses, source codes, and appeal results can be tied back to who was actually mailed. Merging a constituent afterward does not rewrite that history. If you view or export an older activated effort, you may see the pre-merge record.
That’s arguably correct behavior for reporting: the mail really did go to that record. It only becomes a problem when someone reuses an old effort or its output as the basis for a new mailing.
What to do: Treat activated efforts as history, not as a source list. Build each new mailing from a current selection. If you’re not sure how your version of Altru handles records merged after activation, test it in a sandbox or ask Blackbaud support before relying on it for a large appeal.
Cause 3: the old lookup ID came along to the surviving record
Depending on how the merge was configured, information from the source record can be carried onto the target record. If your export or query pulls a field such as an alternate lookup ID, or a list of all IDs on the record, the old number may appear even though only one constituent exists. Check the output field list in your export definition or query and confirm you’re pulling the primary lookup ID.
We’d suggest confirming the exact merge behavior in your own database rather than assuming. Merge a pair of test records in a sandbox and look at what lands on the surviving record.
Cause 4: the duplicate was never merged
Sometimes the “merged” person was actually only partly cleaned up. One duplicate pair got merged, but a third record with a slightly different name or email is still sitting there. Or the individual record was merged but a household that contains the old record wasn’t reviewed. Efforts that pull both individuals and households can return what looks like the same person twice.
What to do: Run a duplicate check by email and by name plus address before each major mailing. Also review household membership for anyone you merge, so the household and the individual don’t both qualify for the same piece.
A routine that prevents most of this
- Finish duplicate review and merges for the period before anyone builds the mailing list.
- Build or refresh the selection after merges are done, ideally as a dynamic selection.
- Before activating, run a quick query against the selection for records with the same email or same name and address. Anything that comes back is worth a look.
- Activate the effort, export, and don’t reuse that output for the next mailing.
- Write down the order of operations so whoever owns merges and whoever owns appeals aren’t working on different calendars.
The timing piece matters most. Many organizations have one person doing data cleanup and another building appeals, and the two jobs overlap. A shared “merge freeze” date a few days before each list pull solves a lot.
Keeping duplicates from piling up
The fewer duplicates you carry into a mailing, the less any of the issues above can bite. Social Good’s Deduper finds and helps fix duplicate constituent and email records in Altru, which makes it practical to do a cleanup pass before every list pull instead of a few times a year. It doesn’t change how marketing efforts store their lists, so the selection and timing steps above still apply.
Quick answers
Will re-running an old activated effort pick up the merge?
Don’t count on it. Activated efforts are meant to preserve who was mailed. Build a new selection for a new mailing.
Is a static selection ever the right choice?
Yes, when you need a fixed record of a list at a point in time. Just save it after merges are complete, and don’t reuse it months later.
