Merging repoints, it does not marry — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for whoever at GadgetSphere has two records for the same company and is deciding what to do about it. In about thirteen minutes you will know what the merge button really does to your database, the two categories of thing it will not touch, what it leaves behind, and how to decide whether a given pair is safe.

Step 1 — See what the screen offers you

After this step you will know how candidates are found. You pick one matching criterion — name, identity number, phone or e-mail — type at least two characters and set a similarity threshold, which starts at nought point seven. The search is fuzzy rather than exact, so near-misses surface. Results come back grouped by the matched value. In each group you mark exactly one record to keep and one or more to fold into it; the action is refused with anything else. Confirming does not merge anything on the spot. It queues a job, and a second screen shows you the queue.

Reference: Supplier — Entity merging

Step 2 — Understand what the job actually runs

After this step you will know why this is not a normal update. The merge does not work from a list of tables somebody wrote down. It inspects the database at the moment it runs and selects its own targets by two rules: every column of identifier type whose name contains the word entity, and every column carrying a declared foreign key to the entity table. Then it rewrites those columns, by value, from the old records to the one you kept. It is a sweep of the whole database, not a patch of a known set of places.

Reference: Supplier — Entity merging

Step 3 — Know what that reaches

After this step you will know the blast radius. It reaches posted documents, journal rows and balance tables, with no filter for status, for posting state, or for a closed fiscal period. On the generic document header alone it rewrites seventeen columns — the customer or supplier on the document, the e-invoice buyer and supplier blocks, the sales agent, the reseller, the shipping recipient and more. Which means documents you issued years ago now name the surviving record. That is usually exactly what you wanted, and it is worth knowing that history is being rewritten rather than annotated.

Reference: Supplier — Entity merging

Step 4 — Learn the two things it will not do

After this step you will know where to look afterwards. First, discovery is not completeness. A column that holds an entity reference under a name without the word entity in it, and without a declared foreign key, is invisible to both rules and keeps pointing at the record you merged away. In one tenant’s schema there are twenty-nine such columns; the one that matters most is the default sales agent sitting on other entity records, which ninety-six thousand records across thirty-four tenants have set. Second, nothing at all is copied from the losers. A tax number, an address or a credit limit held only by the record you folded in stays only on it.

Reference: Supplier — Entity merging

Step 5 — Know what is left behind and what is recorded

After this step you will know what evidence a merge leaves. The records you merged away are not deleted. They are set to inactive, so they stay findable if you search with the status filter open, still holding whatever fields were never copied across. The history table records one row per losing record with a count of how many rows were touched — not which rows. So there is no list to work from if you want to reverse it, and there is nothing stopping somebody editing or transacting against one of these records while the job is running.

Reference: Supplier — Entity merging

Step 6 — Decide whether to merge this pair

After this step you will have a routine. Open both records side by side and copy anything the survivor lacks onto the survivor first — tax numbers, e-invoice identity, addresses, credit terms, the AR or AP type — because the merge will not. Check they are the same kind of thing: nothing stops a customer being merged into a supplier, because they are rows in one table. Then run it out of hours. For scale, the whole platform has recorded about seven hundred and seventy merges across every tenant database together, with the median tenant having none. This is a rare, deliberate operation, and it is one way.

Reference: Entity Maintenance — Overview

How the steps fit together

    flowchart TD
  s1["Step 1 — See what the screen offers you"]
  s2["Step 2 — Understand what the job actually runs"]
  s3["Step 3 — Know what that reaches"]
  s4["Step 4 — Learn the two things it will not do"]
  s5["Step 5 — Know what is left behind and what is recorded"]
  s6["Step 6 — Decide whether to merge this pair"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Back to the series · Play this as a presentation