The problem


A matching model evaluates fields on a single object. When the values that determine whether two records are duplicates live on child records, the model has nothing to match on.


The most common case is Person Account or Individual data models, where email and phone addresses are stored as ContactPointEmail and ContactPointPhone records rather than fields on the Account. Two Accounts might share an email address, but from the Account object alone they look unrelated. The same situation arises with custom alternate-email objects, membership numbers on a junction object, or any identifier held by a related record.


Before you build this: if the value sits on the same record, or one lookup away, a formula field is simpler — normalize it into a helper field and match on that. This article covers the remaining case, where values must be pulled up from children to a parent, which formulas and roll-up summaries cannot do for text.



The solution


A two-pass process:

  1. Pass 1 — match on the child object. A dataset on ContactPointEmail finds groups of contact points sharing an address, using a Classic or AI matching model.
  2. Stamp instead of merge. That dataset's merge is overridden by a custom Flow. Rather than merging the contact points, the Flow writes the group's master record ID onto every parent Account in the group.
  3. Pass 2 — match on the parent object. A dataset on Account uses an exact-match model on the stamped field and performs the merge with your normal Master Record and Field Merge Rules.

Matching happens at the child layer, where the values actually live; the master record ID carries the resulting group identity up to the parent.


Step by step


1. Create the stamp fields on the parent object


Add a text field, e.g. Dedupe_Key__c (18 characters is sufficient). Mark it as an External ID so it is indexed.

Optionally add a second text field such as Dedupe_Key_Source__c to hold the master's email address, for audit and troubleshooting. No matching model should reference this field.


2. Build the child dataset


Create a dataset on ContactPointEmail with a matching model on the email value. Set a deterministic Master Record Rule — earliest CreatedDate works well — so the same record is chosen as master on every run.


3. Create the custom merge Flow


Navigate to Setup → Flows → New Flow and select the "DataGroomr - Custom Merge Flow" template, included in the DataGroomr Duplicates managed package. The template contains:

  • Start — DataGroomr invokes the Flow with the merge request in JSON
  • Iterate Merge Requests — loops the mergeRequests collection, one item per matched group
  • MergeRequests Parse — unpacks each item into Master Record ID, Duplicate Record IDs, Master Record, Duplicate Records, Is Success, Error Message
  • Execute Merge — performs the native Salesforce merge
  • Add Result to Response Collection — accumulates into mergeResponses
  • End — returns mergeResponses to DataGroomr


4. Replace the merge with stamping


Delete the Execute Merge element and put your stamping logic in its place:

  1. From the Duplicate Records collection, read the ParentId of each contact point.
  2. Check whether any of those parent records already carries a value in Dedupe_Key__c. If one does, reuse it. If none does, use Master Record ID.
  3. Assign that value to each parent record and add them to a record collection.
  4. Update the collection once, after the loop — not inside it.


Reusing an existing stamp in step 2 keeps groups stable when master selection shifts between runs, and correctly handles cases where one contact point falls into different groups on different runs. Updating after the loop in step 4 avoids governor limits.


Keep Add Result to Response Collection populated and continue returning mergeResponses. This feeds the Audit log and the interface; without it, the stamping runs with no visible record.


Save the Flow, click Show Advanced, set Source Template to "DataGroomr - Custom Merge Flow", then save and activate.

If Flow governor limits become a constraint at high volume, see Overriding standard Merge method using Apex for the equivalent approach.


5. Assign the Flow to the child dataset


Open the child dataset, go to the Merge tab, and select your Flow in the Override standard merge field. Save.


6. Build the parent dataset


Create a dataset on Account with an exact-match model on Dedupe_Key__c. Apply your Master Record Rule and Field Merge Rules as normal.


Filter out records where the key is blank. Empty values match one another and will group every unstamped record into a single very large false-positive group.


7. Test, then schedule


Run the child dataset first and confirm parent records are being stamped as expected. Then run the parent dataset and perform one merge manually, signed in as the integration user, before scheduling anything.


DataGroomr uses the native Salesforce merge, so any Flow, validation rule, or Apex trigger on the parent object executes inside the merge transaction. A failure there fails the merge — often reported as "0 records merged" with the underlying cause visible only when merging a single group by hand. Permission-dependent automation is a frequent culprit.


In the Automate module, schedule the child dataset to run before the parent dataset so stamps are current before matching.


Related articles