Lead Routing: Diagnose Input Defects Before Rewriting Rules

What Lead Routing Decides and What It Does Not Decide

Lead routing assigns a record to a user, team, or queue under defined conditions. What question are you debugging? This diagnosis does not score the lead, qualify it, redesign territories, enrich the CRM, interpret sales signals, or prescribe workflow implementation. Those decisions can feed or follow routing, but they do not tell you which branch L-204 took.

An OKKI Go lead-generation workflow sits outside that routing decision. A user supplies company-search criteria; the system returns candidate companies and contact context; the user reviews selective unlock and confirms recipient and message choices; the usable result is a reviewed candidate or contact, or a visible send status. None of those documented steps establishes how L-204 received an owner.

Freeze the Record, Actual Assignee, and Evaluated Path

Before you inspect a rule, preserve the L-204 values presented to routing, the expected and actual owners, the route or fallback recorded for the decision, and the active rule version. Also preserve the evaluation time and any configuration change that could have affected your case. A setup audit can identify who changed configuration, what changed, and when. It does not reconstruct the per-record path by itself.

What Round Robin Needs Before It Can Choose an Eligible Owner

If your active model is round robin, check the eligible owner pool, current user or team eligibility, and the distribution state the documented method uses. Microsoft describes qualifying sellers and a last-assigned basis for round robin. HubSpot documents active and eligible owners, equal distribution, and an option to overwrite an existing owner. Does your saved decision state match today's screen? If not, today's apparent next owner cannot explain yesterday's assignment.

What Account Match and Segment Rules Need Before Classification

For account match, inspect the identifiers that create your match. One documented association model compares a contact's email domain with a company's domain name. Which company did L-204 identify at evaluation time? Blank, malformed, shared, or multiply matching domains change the problem before an owner rule runs. Ask whether your record had one supportable account identity, not whether account-based routing is generally preferable.

For a segment or territory-based rule, inspect the record attributes that establish segment membership and the seller or team attributes that establish eligibility. Which fields did your active rule read? Region may be one, but your contract can also include product, language, status, or another locally approved criterion. This is not territory planning. It checks whether the classification facts used for L-204 existed and were current.

How Missing, Stale, Ambiguous, and Conflicting Inputs Split the Diagnosis

Before you decide who or what should change, place the defect in one category. What was true when L-204 was evaluated? Each category asks a different factual question about that state. The labels lead you to different repairs: supply an absent fact, restore the valid snapshot, request a human interpretation, or settle an explicit precedence conflict.

• Missing: a field or state required by the active model was absent when L-204 was evaluated. The rule could not test the intended condition.
• Stale: the value existed, but the saved decision snapshot differed from the approved value in force at that time. Repair the source or synchronization path, then replay.
• Ambiguous: the available value supported more than one identity, segment, or destination. Do not force one interpretation merely to keep automation moving.
• Conflicting: two valid-looking signals disagreed, such as an existing owner and an automated rotation configured to preserve it, or an external ownership sync restoring a prior owner. Resolve precedence before calling either rule correct.

When the Record Must Leave Automation for a Manual Exception Queue

Send L-204 to a manual exception queue when your system cannot justify one individual owner from the preserved inputs. A required value may be unrecoverable, multiple matches may remain supportable, or ownership signals may still conflict. What should travel with the record? Attach the failed contract field, candidate destinations, saved route, rule version, and escalation reason. Your reviewer must resolve or reject the assignment and record that outcome.

A queue is a holding state, not evidence of a successful owner decision. Salesforce documents that queued records can remain there until a member takes ownership. Has someone accepted your disputed record? Queue entry ends automation for that choice; it does not end your incident. A queue with no named resolver, resolution condition, or recorded outcome is an unresolved exception path.

Compare the Documented Rule Order With the Path the Record Took

Dynamics 365 and Salesforce documentation describe ordered evaluation in which a first match prevents later entries from being considered. Which condition matched first under your saved version? If a broad West-team condition matched before a more specific Central-team condition, and your approved specification required Central, the evidence now points to ordering or criteria logic. If the preserved path never evaluated that version, the version or activation state remains the issue.

Separate a Rule Defect From an Exception That Was Never Resolved

A correct rule can still produce an operationally wrong ending. Did L-204 meet your documented exception condition and enter the intended queue? If so, the automated branch adhered to its rule. If no queue member reviewed or took ownership, your defect sits in exception resolution. Changing the match criteria would conceal that handoff failure and may send genuinely ambiguous records to an unsupported owner.

What the Original Record Does After an Input Repair

Where does L-204 go after your input repair? If it takes the approved Central branch, stop. The replay supports an input defect and does not prove that your rule needed revision. If unresolved ambiguity or conflict remains, the correct result is the manual exception queue, followed by a recorded human resolution. Forcing Central would erase the condition the queue exists to preserve.

What a Rule Revision May Change and What It Cannot Establish

If your input contract passes and L-204 still takes the documented wrong branch, revise the specific criterion, precedence, or destination that the trace exposes. What changes on your next replay? A changed path can establish adherence to the approved assignment specification. It cannot establish faster response, fairer workloads, higher conversion, or more revenue; those require separate measures and evidence.

Can you name the failed layer? Repair inputs when your contract fails. Resolve the human handoff when your rule correctly produces an exception. Change rule logic only when current, complete inputs reproduce the wrong branch under the intended version. Keep the same wrong assignment through your investigation, so each change answers which layer failed instead of merely making the symptom disappear.