Dedupe decision code reference
Buyers ask for a "decision code reference" because they want to know why two records merged or did not merge. In Gremlin dedupe, that answer is not one neat taxonomy file. It is a set of actual code surfaces: cluster type, recommended action, anchors, confidence, review notes, approvals, skip reasons, and pair-level evidence.
Cluster types
A cluster where all members are the same Salesforce object type and can be merged as one object family.
A mixed Lead and Contact cluster that the planner treats as a lead-to-contact review case, not a blind same-object merge.
A cross-object cluster that still needs manual judgment because the members do not fit a simpler same-object merge or one-lead-one-contact conversion pattern.
Recommended actions
The planner recommends a same-object merge operation.
The planner recommends a Lead-to-Contact resolution path. Apply can only auto-translate this when the cluster is exactly one Lead plus one Contact.
Approval states
Cluster is allowed to execute when passed via --approval-file.
Cluster stays queued for more review and does not execute.
Cluster is explicitly denied and does not execute.
Cluster still needs a human decision and should not run.
Pair-level reason surfaces
The matched anchor used during blocking or pair scoring, surfaced on pair outputs and cluster payloads.
Pair-level evidence for exact email alignment when that signal is present.
Pair-level name similarity evidence when name similarity clears threshold.
Pair-level evidence for exact company alignment on Lead comparisons.
Lower-level pair outputs can carry a rollup score plus flags such as email_exact, name_strong, company_match, or ensemble_signals.
Execution skip reasons
These values matter because they tell the operator why a cluster did not run even after the plan existed. This is where the apply layer becomes honest about missing approvals, bad overrides, unsupported object types, and mixed clusters that still need manual work.
approval_missing
The apply step required an approval file, but the cluster had no decision row.
approval_not_approved
The cluster was present in the approval file, but the decision was not approved.
invalid_override_master_id
The operator-supplied override_master_id did not resolve to a valid member of the cluster.
requires_manual_cross_object_resolution
The cluster was cross-object or more complex than the one-lead-one-contact path that can be safely translated into convertLead.
unsupported_action
The planner recommended an action that the apply layer does not know how to execute.
missing_master_id
The cluster did not contain a valid survivor record ID at apply time.
mixed_object_types
The merge path expected a same-object cluster but saw mixed object types.
unsupported_object_type
The apply layer supports Account, Contact, and Lead same-object merges. Anything else is skipped.
no_victim_records
There were no remaining victim IDs after the survivor was resolved.
What to say on this page, honestly
Say that Gremlin emits real evidence surfaces an operator can review.
Say that approval, skip, and reason fields exist in code and receipts.
Do not invent a clean SAFE/REVIEW/BLOCK taxonomy that the dedupe workflow does not ship today.
Read next
The audit-first pillar: blocking-first planning, cluster review, supervised merge, receipts, and where native duplicate rules fall short.
Rule-based matching, duplicate-record-set limits, and why alert-or-block is not the same as reviewable clustering.
How to preflight converted status, dry-run the plan, and keep lead-status side effects in view.
A candid page on account duplicate cleanup, what native rules do, and where the public Gremlin workflow stops today.
FAQ
Does Gremlin dedupe have one formal decision-code taxonomy like L2A?
No. The shipped Salesforce dedupe workflow does not emit one monolithic SAFE/REVIEW/BLOCK taxonomy. Instead, the review and apply surfaces are distributed across cluster_type, recommended_action, anchors, merge_confidence, review_notes, approval_status, skip reasons, and pair-level evidence fields.
What should an operator read first in a cluster?
Start with cluster_type, recommended_action, anchors, merge_confidence, and review_notes. Those fields explain what kind of cluster you are looking at, what the planner recommends, why the records clustered, and what caveats still need human attention.
Where do the actual skip reasons live?
In the apply layer and receipt payload. Skips such as approval_missing, approval_not_approved, invalid_override_master_id, requires_manual_cross_object_resolution, and unsupported_object_type are real strings emitted by the execution path.
Keep the conversation going
These pages are meant to help operators solve real problems. If you want the next guide, grab the low-friction option. If you need the implementation, not just the guide, book time.
Get the next guide when it ships
I publish architecture guides grounded in real implementations. No generic AI filler.
Use your work email so I can keep the list useful and relevant.
Need the implementation, not just the guide?
Book a 15-minute working session with Mike right on his calendar. Tooling, consulting, or a mix of both is fine.
Open Mike's calendarIf you want me to come in with context, leave your email and a short note before the call.