Lead Matched to Parent Instead of Child Account in Salesforce
The AE for the Phoenix facility is complaining again. The lead keeps landing on the parent holding company, not the regional child that should own it. Or the reverse — the lead lands on a sibling child when the ultimate parent is the real buying entity. Domain alone cannot pick, and neither should an opaque score.
A governed matcher refuses to auto-pick between parent and child when the evidence is comparable. It emits L2A_REVIEW_PARENT_CHILD_COLLISION, buckets the row into a hierarchy review queue, and lets operators encode the owning level explicitly.
Published April 18, 2026 • Gremlin Salesforce L2A is currently in private beta
Short answer
Gremlin emits L2A_REVIEW_PARENT_CHILD_COLLISION and buckets the row into grouped_exceptions/parent_child/. Operators decide which level of the hierarchy owns the lead and encode that choice in known_account_map. The next scout run picks up the override via the fingerprint.
Resolution workflow
Trace the colliding lead
trace surfaces every candidate in the hierarchy — parent, children, and shared-domain siblings. Evidence chain shows which accounts participate.
Open grouped_exceptions/parent_child/
Scout buckets parent/child collisions into one folder so operators can resolve batches by hierarchy instead of row-by-row.
Choose the level that owns the lead
Facility-level child, regional subsidiary, or ultimate parent — each org has a policy. The matcher surfaces candidates; operators encode the choice.
Encode the choice in known_account_map
Persistent overrides live in gremlin.l2a.yaml or an imported CSV. Exact domain or explicitly approved suffix domain — no regex, no fuzzy aliases.
Re-scout and verify
Map entries participate in the fingerprint, so changes invalidate SKIP_NO_RELEVANT_CHANGE for affected leads. Scout picks up the override on the next run.
Collision patterns
Four shapes that show up in real enterprise orgs. Each has a specific decision code and a specific resolution path.
Parent and child share exact domain
acme.com resolves to both Acme Holdings and Acme North America
L2A_REVIEW_PARENT_CHILD_COLLISION — operator encodes the owning level in known_account_map
Child has a specific subdomain
eu.acme.com resolves to Acme Europe, parent domain resolves to Acme Holdings
suffix_domains entry in known_account_map maps eu.acme.com directly to Acme Europe
Multiple active children share domain
Three sibling accounts all use acme.com and no child is the ultimate parent
L2A_REVIEW_ACCOUNT_GRAPH_AMBIGUOUS — policy decision required before an override is safe
Inactive parent with one active child
Legacy parent account is inactive; a single active child uses the domain
L2A_SAFE_EXACT_DOMAIN_SINGLE_ACCOUNT on the active child — inactive accounts drop out of the candidate set
Encoding the choice
known_account_map accepts exact domains and explicitly approved suffix domains. No regex, no fuzzy aliases.
known_account_map:
exact_domains:
acme.com: 001xx000003ABC2AAO # Acme North America (not Acme Holdings)
suffix_domains:
eu.acme.com: 001xx000003ABC5AAO # Acme Europe
apac.acme.com: 001xx000003ABC6AAO # Acme APACMap contents participate in the evaluation fingerprint. Changing an entry invalidates the SKIP_NO_RELEVANT_CHANGE cache for affected leads and the next scout run picks up the override.
Do not conflate hierarchy resolution with routing
Picking the right level of the hierarchy is a matching decision. Assigning the resulting lead to an owner, territory, or queue is a routing decision. Gremlin does not do the second one. If the org uses hierarchy level to drive routing, that logic lives in assignment rules, Flow, or a routing platform — and it is exactly the kind of downstream automation the risk audit is designed to surface.
FAQ
Why is my lead matching to the parent account instead of the child?
Usually because the parent and child share a domain and the incumbent matcher picks the first (or highest) active account at that domain — which is often the parent. A governed matcher will not auto-pick in that scenario; it emits L2A_REVIEW_PARENT_CHILD_COLLISION and routes to review so an operator can encode the owning level. The fix is to teach the matcher which level owns the lead via a known-account override, not to adjust a similarity threshold.
Can I force leads to match to the ultimate parent or to the child consistently?
Yes, per domain or per suffix, via known_account_map. An exact_domains entry maps acme.com directly to the account you pick (parent or child). A suffix_domains entry handles regional subdomains like eu.acme.com mapping to a specific subsidiary. Both are deterministic, both participate in the evaluation fingerprint, and both ship through the governed apply path.
Why does Gremlin refuse to auto-pick between parent and child?
Because the right answer depends on an org-level policy. Some teams want leads routed to the facility-level child; others want the ultimate parent to own them; others want the regional subsidiary. The matcher cannot infer that from domain alone, so it emits L2A_REVIEW_PARENT_CHILD_COLLISION and lets operators encode the choice explicitly.
What is L2A_REVIEW_PARENT_CHILD_COLLISION?
A review-only decision code that fires when two or more candidate accounts in the same hierarchy match the lead with comparable evidence. The row is never auto-applied — it is routed into grouped_exceptions/parent_child/ for an operator decision.
How do I teach Gremlin which level owns a lead?
Update the known_account_map in gremlin.l2a.yaml (or the imported CSV). An exact_domains entry maps a domain directly to an account id; a suffix_domains entry handles regional subdomains. Both participate in the evaluation fingerprint, so changes take effect on the next scout run.
Can I use fuzzy aliases for hierarchy resolution?
Not in v1. Known_account_map accepts exact domains and explicitly approved suffix domains only — no regex, no fuzzy alias rules. This is deliberate: fuzzy hierarchy resolution is where governed matchers become opaque.
What about ultimate parent rollup?
Ultimate parent awareness belongs in the Account graph, not in the matcher output. Gremlin surfaces the candidate hierarchy in trace output and grouped exceptions so operators can see the parent-child chain. Rollup to a parent for reporting is a separate downstream concern and does not change the matched-account write.
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.