---
title: "Rebuilding inbound lead and account routing in native CRM flows — then migrating it back"
type: case-study
evidence_type: proof
category: "Lead Routing & Speed-to-Lead"
publisher: "LeanScale"
date_modified: 2026-08-08
word_count: 817
topics: ["revenue-operations", "demand-generation"]
canonical_url: https://knowledge.leanscale.team/customers/vendor-router-to-native-crm-routing-and-back/
source: "LeanScale Knowledge Hub — https://knowledge.leanscale.team"
license: "Free to quote and cite with attribution to LeanScale."
---

# Rebuilding inbound lead and account routing in native CRM flows — then migrating it back

**Evidence type:** proof (what happened)

A financial-technology company lost its third-party lead router when the subscription lapsed, with no documentation of how routing worked. LeanScale reverse-engineered the logic, rebuilt lead and account routing as native CRM flows, ran it in production, and then used the same documentation to migrate routing back when the vendor was renewed.

## The challenge

Inbound leads and accounts were routed by a third-party router bolted onto a large CRM — on the order of eighty thousand leads, fifty thousand accounts, two hundred and seventy thousand contacts and nine thousand opportunities. The subscription lapsed and routing had to move, fast. Nobody had a written record of how the existing routing actually worked: every path, every round robin, and every enrichment dependency lived only inside the tool's UI. Routing quality was already degraded underneath that, because records arriving without firmographics silently fell through to a default owner instead of a rep — which looks like a routing bug and is actually an enrichment bug.

## The approach

Document the black box before touching it
First deliverable was not a build. It was a full reverse-engineering of the incumbent router: every routing path and its logic, every round robin and its membership, and exactly where enrichment ran inside the routing flow — written up as a standalone spec that lived outside the vendor. That single document ended up driving both migrations.

Evaluate the alternatives on the record
Before defaulting to native CRM flows, formally assessed whether the enrichment and GTM data platform already in the stack could reproduce the routing: which of the current routing options existed there, what the pitfalls and limitations were, and specifically what could not be reproduced. Native record-triggered flows won on the parts that mattered — assignment inside the CRM's own permission and validation model.

Two routers, not one
Built a lead router and an account router as separate flows. The lead router matches an inbound lead to an existing account and converts it; the account router assigns ownership. The routing keys were firmographic — industry classification code, employee count, revenue, geography, and email domain — which is precisely why enrichment coverage determines routing accuracy.

Launch with a notification spine
Every record hitting the router copied the client's RevOps alias and the shared delivery inbox, so misroutes surfaced within minutes instead of at the end of a quarter. The incumbent router was disabled and the native routers enabled inside the same cutover window. An end-to-end walkthrough video and written routing documentation shipped to the client's team so the logic was legible to people who had never seen the vendor's UI.

The failure modes were matching, not logic
In production the recurring errors were duplicate and matching problems, not routing decisions: lead conversion failing with a duplicates-detected exception; account-owner updates blocked by a field-level validation rule that only permitted leadership and admins to change ownership (the flow ran as a user without that right); and existing-customer form fills failing to match their own account, because customers adding seats submitted the form with their account name plus a product suffix, so the lookup missed and they were routed to a new rep as net-new business. Fixed by adding existing-client lookups ahead of the assignment step.

Treat enrichment as a routing prerequisite
A batch of a few thousand vertical target accounts pushed into the CRM from the enrichment platform was missing industry classification, full address, website and revenue. Roughly two thousand of them defaulted to a single fallback owner because the router had nothing to route on. The fix was upstream: backfill the firmographics, then re-route the misassigned accounts — not add another routing branch.

Migrate back without redoing the analysis
When the vendor subscription was renewed, the same specification was run in reverse. The vendor's production environment was rebuilt from the extracted logic, round robins were recreated once user licenses were provisioned, and the vendor router was activated while the native CRM routers were deprecated. The enrichment pipeline was re-pointed to match: the enrichment tables stopped pushing directly into the marketing platform and CRM, and instead exported CSVs uploaded through the vendor so its dedupe and routing ran on every record.

Make monitoring a standing line item
Router error monitoring was created as its own recurring ticket rather than being absorbed into ad-hoc firefighting, so time spent investigating routing failures was visible and budgeted. Notification behaviour got the same treatment — a separate investigation covered why assigned reps were not receiving lead-assignment emails.

## Outcomes

Routing survived a tool outage and a tool return
Inbound lead and account routing ran continuously through the vendor lapse and the vendor's reinstatement, because the routing logic had been documented independently of the tool that executed it.

The documentation became the durable asset
One specification drove the migration off the vendor, the native build, and the rebuild back into the vendor — including the round robins.

Ownership defaults corrected at the source
Backfilling firmographics moved roughly two thousand accounts off a single fallback owner and onto the correct reps, and the enrichment gap was closed ahead of routing rather than patched after.

Existing customers stopped being routed as strangers
Adding existing-client lookups before assignment stopped seat-expansion form fills from being treated as net-new leads and handed to the wrong rep.

## Canonical

https://knowledge.leanscale.team/customers/vendor-router-to-native-crm-routing-and-back/