Public SaaS Record Merge Evidence Guide

A record merge can look successful while quietly losing history, duplicating relationships, or assigning the surviving identity to the wrong source. This guide defines a small, repeatable evidence method for checking one bounded merge claim in a public web or mobile SaaS workflow. It is written for reviewers who need an auditable result, not a broad promise that every merge implementation behaves the same way.

Define one bounded claim

Start with a precise statement such as: when two authorized test records are merged, the selected primary record survives, documented secondary fields are reconciled, supported relationships remain attached, and the secondary record can no longer be used as an independent active identity. Keep the claim limited to the product area, role, plan, region, device class, and version that you actually test. If a field, relationship, or recovery behavior is undocumented, mark it outside the claim instead of guessing.

Use disposable synthetic records

Create two test records that contain no real personal, customer, payment, health, legal, or credential data. Give each record a clearly different synthetic name and a unique marker. Add only the minimum fields needed to exercise the documented merge path. For example, Record Alpha can contain a safe note marker and Record Beta can contain a different tag. If the workflow supports related objects, attach one authorized disposable relationship to each record. Never merge production identities merely to collect evidence.

Capture the source contract

Before the merge, record the documented rule for choosing the survivor and reconciling fields. Note whether the interface promises selection, automatic precedence, conflict review, or a fixed primary record. Capture the visible record identifiers, last-updated times, supported relationship counts, and the role used for the test. Evidence should show what the system was asked to do. A screenshot of a success message without the input contract cannot prove that reconciliation was correct.

Confirm authorization and scope

Verify that the current role is allowed to merge these exact disposable records. If the product separates view, edit, merge, archive, and restore permissions, test only the permission boundary relevant to the claim. Do not probe another tenant, bypass a disabled control, alter a request, or use an undocumented endpoint. A denied action is valid negative evidence when it is produced through the ordinary interface and the expected policy.

Record the before state

Open each test record independently and capture its stable identifier, visible fields, safe markers, relationship list, and lifecycle state. Reload each page once so the baseline is not merely an unsaved client view. If there is a public or export representation that the tester is authorized to use, capture it as a separate source. Keep times in one declared timezone and include the device or viewport class. This makes later comparisons reproducible.