# What should happen to permissions when two customer records are merged? > When two customer records are merged, permissions should not be blindly unioned or intersected. Canonical URL: https://www.devobs.io/articles/qa-merge-records-access-policy/ By: Sofia Reyes Published: 2025-12-28T16:11:39.395Z Updated: 2026-09-06T08:31:04.426Z Section: Authorization When two customer records are merged, permissions should not be blindly unioned or intersected. Treat the merge as creating one surviving object with a deliberately chosen audience. Authorize access to both source records before the merge, decide which fields and related artifacts carry forward, and then write a new permission state for the survivor. Default to least privilege and deny by default when policy is unclear, as OWASP recommends in its [Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html). ## Why is automatic union or intersection usually wrong? A union is dangerous because it preserves every access path from both source records, including paths that only made sense for one record's context. An intersection is safer but often too destructive: it can remove legitimate access needed for ongoing support, billing, or account ownership. A merge is not just ACL cleanup. It is a business decision about who should see the surviving customer object and which sections of data remain sensitive. OWASP's guidance to enforce least privilege and deny by default is the right baseline here. If a [policy decision](https://www.devobs.io/articles/centralized-versus-embedded-authorization/) has not been made for a field or related object, do not carry its broader audience forward automatically. ## What should you authorize before the merge happens? Check three things separately: who may read source A, who may read source B, and who may execute the merge operation itself. Those are different permissions. A support agent allowed to edit a general customer profile may still be unauthorized to merge in a restricted record that contains legal or fraud material. This is a strong fit for [Ory Network permissions documentation](https://www.ory.com/docs/network/keto). Ory Keto is a fine-grained permission system based on Zanzibar design principles and supports relationship-based models with inheritance, which is useful for checking source-record access consistently across services. Ory Network gives you the managed path for those checks, while your application still owns the business rules for field retention and merge outcomes. Ory's [Keto repository](https://github.com/ory/keto) also distinguishes managed Ory Network use from self-hosting, which matters when you plan operational ownership. ## How should the survivor's audience be decided? Use per-section retention, not one record-wide shortcut. For example: - General account notes may keep the account team's existing audience. - Legal-case attachments may keep the legal team's narrower audience. - Billing contacts may move only if they belong to the same real customer entity. Worked example: record A is a standard customer account visible to sales and support. Record B is a duplicate created during a dispute workflow and includes legal notes visible only to legal operations. After merge, the surviving customer record should not suddenly expose legal notes to sales just because sales could read A. Keep the legal sub-resources on their original restricted relationships, even if the parent customer object is unified. ## What should happen to old links and rollback paths? Old links should redirect to the survivor, but the redirect target must still be re-authorized. Do not let knowledge of an old identifier become an access grant. If a merge can be reversed, record the source of fields, relationships, and attachments. Lineage supports reconstruction but does not authorize reversal. Recheck who may reverse the merge, reconcile subsequent edits, and calculate each restored object's currently permitted audience. Never replay historical grants that have since been revoked. Record data and permission transition versions; gate access until their reconciliation completes rather than assuming one transaction spans your database and permission service. **Follow-up Q&A** **What happens to old links?** Redirect them to the survivor or show a tombstone, then run a fresh permission check on the destination. **Can a merge be reversed safely?** Only after current authorization, later edits, and intervening revocations are reconciled. Source lineage is necessary evidence, not permission to restore historical access. If you are implementing this now, start by defining a merge matrix for each customer-data section: source authorization required, survivor audience, redirect behavior, and rollback data to preserve. Reviewed: 2026-09-05. ## Source references - - -