Merge History
Every time you merge two person records together, TimelyChurch writes a permanent entry to the Merge History log. This article explains what gets logged, how to read the log, and how to reverse a merge that should not have happened.
Why Keep a Merge Log?
Merging two people is a destructive-feeling operation -- you collapse two histories into one, and the secondary record is archived. A reliable audit trail gives you:
- Accountability -- Who merged whom, and when.
- Recovery -- If a merge was wrong, you can see exactly what was combined and undo it.
- Compliance -- For churches operating under SOC 2 or similar frameworks, a tamper-resistant record of who changed what is essential.
Where to Find It
- From the admin portal, navigate to People > Merge History.
- You will see a reverse-chronological list of every merge that has happened in your church.
Each row shows:
- Primary Person -- The record that was kept (clickable to open the profile)
- Secondary Person -- The name of the record that was archived (taken from the snapshot, since the record is now soft-deleted)
- Merged By -- The staff member who performed the merge
- Merged At -- The date and time of the merge
- Records Transferred -- A summary of what was moved (e.g., "12 Group Memberships, 3 Notes, 1 Family Membership")
- Notes -- Any free-text notes the merger added at confirmation time
What Gets Logged
For each merge, TimelyChurch writes a PersonMergeLog entry that captures:
Identity
- The church_id (every merge is scoped to its tenant)
- The primary person ID (the one that remains)
- The secondary person ID (the one that was archived)
Snapshot
- A full snapshot of the secondary person record at the moment of the merge -- name, email, phone, address, birthdate, gender, custom fields. This snapshot is what powers the "Secondary Person" name shown in the log even after the underlying record is purged.
Counts of Transferred Records
The log records how many of each related record type were moved from the secondary to the primary. The recognized record types include:
| Record Type | What It Counts |
|---|---|
| Group Memberships | Small group, class, and team memberships |
| Attendance Records | Attendance entries tied to the secondary person |
| Check-ins | Check-in events |
| Follow-ups | Open and completed follow-up tasks |
| Notes | Pastoral, prayer, and general notes |
| Donations | Giving records |
| Pledges | Pledges and pledge campaigns |
| Form Submissions | Connection card and form submissions |
| Volunteer Assignments | Active volunteer roles |
| Family Memberships | Memberships in any family unit |
| Custom Field Values | Stored values for custom fields |
| Self-References | Cross-references where another record pointed at the secondary |
If a particular type was zero, it is omitted from the summary so you only see what actually moved.
Field Choices
- A record of which field-by-field choice was made during the merge -- for example, "kept primary's email, took secondary's birthdate." This is captured for the side-by-side merge flow that lets you choose between conflicting values.
Authorship
- The merged_by user ID
- The merged_at timestamp
- Free-text notes the operator typed at confirmation
Reading a Merge Log Entry
When you click a row in the Merge History page, you see a detail view with:
- The names of both records (primary stays clickable; secondary opens an archived view if needed)
- The full count of transferred records
- The field-by-field decision matrix
- Who performed the merge and when
- Any notes at the time
This is enough to reconstruct exactly what happened. If a member calls and says "you merged me with my brother," you have the data to verify -- and to reverse if needed.
Reversing a Bad Merge
A wrong merge is recoverable, but it requires staff intervention. There is no one-click "Undo Merge" button because the surrounding records (donations, attendance) have already been re-attributed.
Recovery Pattern
- Open People > Merge History and find the bad merge.
- Note the secondary person ID -- their record was soft-deleted, not destroyed.
- From the People page, switch to the Archived filter and find the secondary person record.
- Click Restore to bring them back to your active directory.
- Open the primary person profile and manually move back any records that were transferred but should not have been -- usually the most relevant are family memberships, group memberships, and notes.
- Use the merge log's field-choice list to know which contact-info fields to revert on the primary if the wrong values were kept.
If your church has a lot of activity on the merged records, this can be tedious. The audit trail is what makes it possible at all.
Tip: If you discover a bad merge quickly (same day, before the secondary person has any new activity), it is much easier to recover than if it has been weeks. Build a habit of reviewing the merge log shortly after performing merges, especially during a duplicate-cleanup push.
Best Practices
- Always add notes when merging. A one-line "Confirmed by phone with John" pays off later.
- Use the side-by-side merge for borderline cases. It captures field choices in the audit log.
- Review the Merge History page weekly during cleanup pushes. This catches mistakes early.
- Train multiple staff on merge protocol. When only one person knows how merges are done, mistakes go unnoticed.
- Treat the secondary person ID as a permanent reference. If you ever need support, that ID and the merge log entry tell us exactly what happened.
Privacy and Retention
Merge log entries are retained indefinitely by default. The snapshot stored in the log is the secondary person's data at merge time -- it does not update if the primary record changes later. This is intentional: the snapshot is a forensic record, not a live mirror.
If your church has a retention policy that requires purging merge logs after a fixed period, contact support; this is a per-church configuration.