You merge two records for the same member, open the surviving record, and something is missing: a second email address, a note from the development office, a preference flag, maybe a membership you could have sworn was on the other record. Merging in Altru moves a lot, but not everything. It also doesn’t always move things the way you’d expect.
Below is how to think about what survives a merge, what tends to get dropped or overwritten, and how to check before you merge rather than after.
Two records go in, one comes out
Every merge has a source record (the one that goes away) and a target record (the one that stays). Nearly every surprise comes down to which record you picked as which. The rule of thumb:
- Transactional history usually follows the person. Revenue, gifts, ticket orders, membership history, and similar activity are generally reassigned from the source to the target, because losing that history would break giving totals and reporting.
- Single-value fields usually belong to the target. When both records have a value for something that can hold only one answer (a birth date, a primary name format, a single-value attribute), the target’s value is the one most likely to win. The source’s value may simply be discarded.
- Multi-value items depend on configuration. Addresses, phone numbers, email addresses, and multi-value attributes can be copied over, skipped, or marked as non-primary, depending on how your merge settings are set up.
Altru’s merge behavior is driven by configurable merge settings, and organizations rarely revisit them after implementation. If nobody on your team knows what yours are set to, find that out before you trust any list like this one, including ours.
What most often goes missing
These are the areas where administrators most often report something “didn’t carry over.” Whether each one applies to you depends on your configuration and Altru version, so treat this as a checklist to test, not a guarantee.
Contact information
If the source record had the more current email or address and it wasn’t set to copy, the target keeps its older information. Even when it does copy, the source’s primary email may come over as a secondary one. That matters a lot if your eTickets, receipts, and renewal notices go to the primary address.
Communication preferences and solicit codes
Do-not-email, do-not-mail, and similar preferences are the riskiest item on the list. If a person opted out on the source record and that preference doesn’t land on the target, you could end up emailing someone who asked you to stop. Check these by hand on every merge where either record has a restriction.
Attributes, notes, and custom fields
Single-value attributes that conflict usually keep the target’s value. Notes and interactions generally move, but confirm it for any custom fields your organization added, since those don’t always behave like standard fields.
Memberships
Membership history generally moves, but two active memberships on two records can’t always be collapsed into one clean membership. You may end up with overlapping terms, a membership that needs to be manually ended, or cardholder and household details that need cleanup. Look at the membership tab on the target right after merging.
Households and relationships
If the source record belonged to a household, the target may not take its place in that household automatically. Relationships to spouses, children, or organizations can come across, duplicate, or need to be re-linked.
Anything that points at the old record from outside
Static selections, saved exports, and spreadsheets that reference the source record’s ID or lookup ID won’t update themselves. Online accounts or logins tied to the source may also need attention. Dynamic queries and smart fields generally recalculate, though smart fields only refresh when their processes run, so totals can look wrong for a while.
Check before you merge
- Pick the target deliberately. Usually that’s the record with the longest giving or membership history, the correct lookup ID, and the most accurate name. Don’t default to whichever one you found first.
- Compare the two records side by side. Write down anything on the source that the target lacks: emails, phones, addresses, preferences, attributes. Those are the items to verify afterward.
- Move the critical items first if you’re unsure. If a newer email or an opt-out lives only on the source, add it to the target before merging. Copying it by hand takes a minute. Recovering it after the source is gone takes much longer.
- Test your settings in a sandbox. Create two test constituents with conflicting data in every category you care about, merge them, and see what survives. If you don’t have a sandbox, Blackbaud support can tell you how your merge configuration is set and what each option does.
- Check the target afterward. Look at contact info, preferences, memberships, and household right after the merge, while the details are still fresh in your head.
Can you undo a merge?
Plan as if you can’t. A merge is not something you can reliably reverse with a single action, and rebuilding a deleted source record by hand loses history. If a merge goes wrong, the realistic fix is to re-add the missing information to the target from your notes, which is one more reason to write those notes down first.
Reducing the merge workload
The fewer duplicates you create, the fewer of these decisions you have to make. Most come from online purchases where a guest typos an email or uses a different one, and from desk sales where staff create a new record instead of searching. Tightening the search habit at the desk, and asking online buyers to use the email you have on file, both help.
For the duplicates that still get through, Social Good’s Deduper finds and fixes duplicate constituent and email records in Altru. It’s useful when the backlog is too large to work through one pair at a time. The same rule applies there as anywhere else: know which record should survive and what you need to keep from the other one.
