Why Is My Lead Match Field Triggering Assignment Rules or Flow in Salesforce?
A lead updates, the matched-account field changes, and suddenly an assignment rule fires, a record-triggered Flow runs, or an owner reassignment lands in a queue nobody expected. The matched-account field is not an innocent annotation — it is wired into routing, territory, and account-side automation.
The risk surface is not which field the matcher touches. It is what automation wakes up when that field changes. The init-time audit answers that question — it scans Apex, Flow, assignment rules, validation rules, formula fields, and duplicate rules for references before any L2A write decision is locked.
Published April 18, 2026 • Gremlin Salesforce L2A is currently in private beta
Short answer
Run g-gremlin salesforce l2a init with the candidate field. The init command scans Apex, Flow, assignment rules, validation rules, and related automation, classifies the field as low_risk, high_risk, or unknown_risk, and emits risk_audit.md plus risk_audit.json. Live shared_existing writes require the audit hash on the apply command line.
What the audit scans
Nine automation surfaces, each capable of turning a field write into a behavioral change.
Apex triggers
Can mutate Lead or Account state on change
Apex classes
Batch jobs, schedulable jobs, and invocable actions
Record-triggered Flow
Most common modern routing path
Workflow rules
Legacy field-change logic still live in many orgs
Process Builder remnants
Dormant automation that can wake unexpectedly
Validation rules
Can block writes in ways that look like permission errors
Assignment rules
Field changes can reassign ownership silently
Formula fields
Propagate the match into reporting and other logic
Duplicate rules
Shift behavior based on a populated match value
Risk classes
Each candidate field lands on one class. Incomplete metadata never implies safety.
| Class | Meaning | Behavior |
|---|---|---|
| low_risk | No references in Apex, Flow, assignment rules, or validation rules | Eligible for shared_existing after an acknowledged risk audit hash |
| high_risk | References found in one or more automation surfaces | Shared_existing live apply requires an explicit risk acknowledgment |
| unknown_risk | Metadata visibility is incomplete — some scan targets could not be inspected | Degrades to observe_existing by default; incomplete metadata never implies safety |
The workflow
Run init with the candidate field
Pass --existing-field to the field you might eventually write. Init scans downstream automation and classifies risk before any mode is locked.
Read risk_audit.md
The audit lists every reference found and the risk class. risk_audit.json carries the same data for machine consumption and is fingerprinted into the config.
Review candidate_fields.csv
Every candidate match field on Lead, with its current automation references and writability. Use this to pick the safest write target.
Decide mode by risk class
Unknown risk stays observe_existing. High risk requires an acknowledged hash. Gremlin_owned sidesteps the question by writing to a namespace no automation references.
Acknowledge the hash at apply time
Live shared_existing writes require --ack-risk-audit on the apply command line. Without it, the write path refuses to run.
Init with the candidate field
g-gremlin salesforce l2a init \
--org-alias prod \
--mode observe_existing \
--existing-field Account_Match__cApply with risk acknowledgment
Live shared_existing writes require both --confirm-plan-hash and --ack-risk-audit.
g-gremlin salesforce l2a apply \
--config ./gremlin.l2a.yaml \
--plan ./artifacts/salesforce_l2a/20260418_101530Z/fix_plan.json \
--apply \
--confirm-plan-hash 9f2c...e104 \
--ack-risk-audit 3ab1...7c55FAQ
Why does my lead match field fire assignment rules or Flow?
Because the matched-account field on Lead is commonly referenced by record-triggered Flow, assignment rules, or formula fields that roll up into territory logic. When the field value changes, those automations fire as if the lead changed owners — because, from their perspective, the lead did. The fix is not to stop writing the field; it is to know which automations reference it before you write.
How do I find every Flow and assignment rule that references a specific Lead field?
The init-time audit scans Apex triggers, Apex classes, record-triggered Flows, workflow rules, Process Builder remnants where visible, validation rules, assignment rules, formula fields, and duplicate rules for references. Each match is captured in risk_audit.md (human) and risk_audit.json (machine) with the source object and mutation path.
Why does a matched-account field change trigger routing?
In a real Salesforce org, the field often feeds assignment rules, record-triggered Flow, territory logic, formula fields, or account-side updates. The write looks like a harmless annotation but can reassign ownership, move the lead into a queue, or fire downstream automation. That is the lesson the audit bakes in.
What does the Gremlin risk audit actually scan?
Apex triggers, Apex classes, record-triggered Flows, workflow rules, Process Builder remnants where visible, validation rules, assignment rules, formula fields, and duplicate rules. Each reference is captured with its source object and the mutation path. Results land in risk_audit.md (human) and risk_audit.json (machine).
What happens if metadata visibility is incomplete?
The field is classified as unknown_risk. Gremlin degrades to observe_existing by default and refuses to promote to shared_existing live apply. Incomplete metadata never implies safety — it is treated as a safety limitation, not a minor warning.
How do I sidestep the risk entirely?
Use gremlin_owned mode. Gremlin writes only to its own namespace (Gremlin_Matched_Account__c, Gremlin_Match_Status__c, and related fields). By design, no existing customer automation references those fields, so the cascade risk does not exist for the write path.
Can I re-run the audit after I change org automation?
Yes. risk_audit.json participates in the config fingerprint, so re-running init after Flow or Apex changes produces a new hash that the apply command will require. Old acknowledgments do not grandfather new automation.
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.