A lead lands on the wrong desk and nobody can say why
I have sat in enough sales ops reviews to recognize the moment. Someone pulls up a lead record, points at the owner field, and asks how it got there. Three people in the room offer three different answers, and none of them match what the system actually did.
This happens in Dynamics 365 shops and Sales Cloud shops in equal measure. Routing logic behind lead assignment starts as a handful of clean rules and turns, over a year or two, into something nobody in the room can fully explain. What actually fixes it is an audit followed by real deletion, not another rule stacked on top of the pile.
Every rule was right on the day it got written
Lead routing usually starts simple. Leads from the east region go to the east team by postal code. Everything else falls into a round robin queue, one rep after another. For the first few months that setup covers almost every case that comes through the form.
Then a strategic account signs a partnership deal and its inbound leads need to skip the queue and land on one named rep. A new product line launches and its leads need a specialist who understands the pricing model. A rep goes on leave and their territory needs a temporary reassignment. Each of these is a real business need, and someone in sales ops adds a rule to handle it, correctly, that same week.
Eighteen months later there are eleven active rules layered on top of the original two, and three of them touch the same lead source under different conditions. Nobody sat down and designed a system with eleven branches. Eleven separate decisions, made by whoever was on call for sales ops that week, each solved one problem in isolation and moved on to the next fire.
Nobody deletes a rule they did not write
The rules pile up because removing one feels riskier than leaving it running. A workflow built by a contractor who left the company two years ago, a Power Automate flow named "Q3 Campaign Exception," an assignment rule in Sales Cloud with no description field filled in. Whoever inherits the system has no way to know what breaks if they turn any of it off.
So the safe move becomes the default move: leave it running, add the new exception on top, and hope the old rule and the new one never fire on the same lead at once. That hope holds for a while. Then a high-value lead sits untouched for four days because two rules each assumed the other one would claim it, and the account executive who should have called on day one hears about it from a Slack message asking why the deal went cold.
This is not unique to lead routing. Automation loses its owner the same way across most of a CRM instance, once the person who built a flow moves to a different team and nobody takes their place as the person who actually understands it.
Trace what fired, not what people assume runs
The audit itself is mechanical, not clever. Pull every lead created in the last full quarter, then trace which rule actually assigned each one. In Sales Cloud's assignment rules, that means walking the entry criteria in the order they are ranked and checking which one matched first. In Dynamics 365's routing flows, it means opening the run history and reading which branch actually executed.
Then do the harder part. Ask the sales ops team, the revenue operations lead, and one or two account executives which rule they believe is running for a handful of those same leads. Write down both answers side by side. The gap between what people assume and what actually fired is the real map of the problem, and it is almost always bigger than anyone expects going in.
I have run this exercise with teams that were certain their round robin was even, only to find one rep had been silently skipped for eight months because an old exclusion rule from a leave of absence never got reversed. Nobody was excluding that rep on purpose. The system just kept doing what it had been told to do once, long after the reason for it was gone.
The rule nobody can explain is usually still running
Every audit like this turns up at least one rule that traces back to a person who no longer works there. It has a name like "Territory Override 2," a condition nobody can fully parse, and leads still flowing through it every week. Nobody remembers what the override was meant to fix. Nobody can say whether it still matches its original intent.
The instinct is to leave it alone because it has not caused a visible problem yet. That instinct is backwards. A rule nobody understands cannot be called stable, and it will eventually catch a lead it was never meant to catch. By the time that surfaces, the person asking why will be three levels removed from anyone who could have explained it.
Once the audit is done, deleting it is the only defensible move, because a rule that cannot be explained cannot be trusted, no matter how long it has been running quietly in the background.
Write the flowchart a new hire could follow unaided
The fix here is a single flowchart, one page, that traces every path a lead can take from form submission to a rep's queue, not a rewrite of the routing engine. Hand it to a new sales ops hire with no other context and watch where they get stuck. Every place they need to ask a question is a gap between the documented system and the real one.
Once that flowchart is accurate, apply one rule without exception. If a live rule cannot be found anywhere on that page, delete it in full, not disabled, not deprecated, not left in place for later. The case for a small center of excellence rests partly on this kind of work, since one group has to own the flowchart or nobody updates it before the next rule gets added.
Put a date on the flowchart and a name next to it, then review it every time the sales org changes its territory model or adds a product line, since that is exactly when the next stray rule gets born. Treat that review the way this desk has argued for a retirement list for old logic: a rule does not get to stay just because deleting it takes an afternoon someone would rather spend elsewhere.
The next time someone asks why a lead landed where it did, do not answer with what the rules were designed to do. Answer with which one actually fired, and watch how many people in the room already knew the difference.
