Pull Routing vs Push Routing in Salesforce: Which Model Is Right for Your Sales Team?

Every routing system answers one question before it answers any others: does the system decide who owns this lead, or does the rep? Almost everything else - fairness, speed, rep autonomy, coverage - follows from that answer, and most teams never make it consciously. They inherit whichever model their first Salesforce admin built and then spend three years patching the symptoms.

‍

Worth doing deliberately. Here's the case for each, the failure mode of each, and the hybrid that most scaled teams end up at.

What is push routing?

Push routing is an assignment model in which the routing system automatically sets a record owner at the moment the record is created or qualified, using rules such as round robin, territory, weighting or account ownership - so every lead arrives already assigned to a named individual.

‍

This is what most people mean by "lead routing". Round robin, territory rules, account-based routing and weighted distribution are all push models. The rep opens Salesforce and finds work waiting for them.

What is pull routing?

Pull routing is an assignment model in which new records land in a shared queue or pool with no individual owner, and reps claim records themselves - taking ownership at the moment they decide to work the lead rather than at the moment it arrives.

‍

In Salesforce this is queue-based. Leads route to a queue, reps view the queue's list view, and claiming is either a manual "Change Owner" or an Accept action. Omni-Channel sits somewhere between the two: it pushes work to available agents but requires them to accept it, which gives you push-like speed with a pull-like consent step.

The trade-offs, side by side.

Time to owner

Push: immediate, milliseconds.
Pull: variable, minutes to never.

Time to first touch

Push: depends entirely on rep availability.
Pull: usually fast for attractive leads, slow for the rest.

Fairness

Push: enforced by the algorithm.
Pull: emergent, and rarely fair.

Cherry-picking risk

Push: none.
Pull: high, and it's the main risk.

Ghost ownership risk

Push: high — leads get assigned to someone on leave.
Pull: low, because nobody owns it until someone acts.

Rep autonomy

Push: low. Pull: high.

Motivation on first call

Push: neutral.
Pull: higher, because the rep chose the lead.

Coverage gaps

Push: silent failure.
Pull: visible failure.

Admin overhead

Push: rules to build and maintain.
Pull: queue design plus behavioural monitoring.

Scales to

Push: high volume, standardised leads.
Pull: lower volume, specialist or complex leads.

Best fit

Push: inbound SDR teams, speed-to-lead motions.
Pull: small senior teams, partner channels, overflow pools.

The cherry-picking problem.

Pull routing's central weakness is that reps optimise for their own commission, which is exactly what you pay them to do. Given a queue, they will take the enterprise logo with the corporate email and leave the SMB lead with the Gmail address. That's rational behaviour producing an irrational outcome: your lowest-effort leads get worked in ninety seconds and your genuinely mixed pipeline develops a permanent sediment of unclaimed records nobody will ever touch.

‍

The tell is easy to spot and almost nobody measures it: queue age at the 90th percentile. Your median might be four minutes and look excellent. If p90 is eleven days, you don't have a fast queue - you have a fast queue and a graveyard.

The ghost ownership problem.

Push routing's central weakness is that assignment isn't the same as attention. A lead assigned to a rep who is on annual leave, in back-to-back meetings, or three weeks from leaving the company is technically owned and functionally abandoned. Worse, it's invisible: every dashboard shows 100% assignment, the SLA clock ticks, and nobody notices until the lead is cold.

‍

This is why serious push routing needs availability awareness - working hours, holiday calendars, presence, capacity caps - and why plain Assignment Rules, which have none of these, produce so many quietly dead leads.

The hybrid models that actually work.

Almost every mature routing setup ends up hybrid. Two patterns dominate.

‍

Push with a claim window. The system assigns an owner immediately, and the rep has a defined window - 5, 10, 15 minutes - to accept or action it. Unactioned leads return to the pool and re-route to the next available rep. You keep push's instant ownership and its fairness, and you eliminate ghost ownership because unattended leads escalate automatically rather than sitting there.

‍

Pull with timed auto-assign. Leads land in a pool and reps can claim freely for a defined window. Anything unclaimed at the end of it gets pushed automatically. Reps keep autonomy over the leads they want; the sediment problem disappears because nothing can sit unclaimed indefinitely.

‍

A third pattern is worth naming: tiered routing, where the model varies by lead value. High-value or named-account leads push directly to their owner (no ambiguity, no delay), while the general inbound flow runs as a pull pool with auto-assign backstop. This maps routing model to lead economics, which is usually the right instinct.

Choosing by team shape.

High-velocity inbound SDR team. Push, with availability and capacity awareness, and a short claim window. Speed dominates everything - as our speed-to-lead guide covers, response time is the variable with the steepest curve, and a pull queue adds latency you cannot afford.

‍

Named-account AE team. Push, account-based. Ownership is predetermined by the relationship, so there's nothing to claim.

‍

Small senior sales team. Pull works well. With five experienced reps who talk to each other, cherry-picking is socially self-regulating and the autonomy is genuinely valuable.

‍

Support and service desks. Push with acceptance - the Omni-Channel model. Skill and capacity should determine assignment, not agent preference.

‍

Partner and channel motions. Pull, usually. Partners claiming from a shared pool is often the only workable model when you can't manage their capacity.

‍

Overflow and after-hours. Pull as a safety valve under a push primary. Anything the push model couldn't place lands in a visible pool rather than a silent one.

Building each in Salesforce.

Push, natively: Lead Assignment Rules for simple field-based logic, or Flow where you need anything conditional. Neither knows about capacity or availability, so both need supplementing at scale - see our guide to assigning leads in Salesforce.

‍

Pull, natively: route to a Queue, give reps list view access, and let them take ownership. Simple to build, and it comes with no monitoring at all - you'll need reports on queue age percentiles and claim rate by lead segment, and you'll need to build those yourself.

‍

Hybrid, natively: this is where it gets awkward. A claim window means tracking assignment timestamps, monitoring for inaction, and re-routing on timeout - a scheduled Flow plus custom fields plus a re-entry path into the original routing logic. It's buildable, it's fragile, and it tends to be the thing that breaks when the person who built it leaves.

‍

Distribution Engine treats push, pull and hybrid as configuration rather than architecture. Rules can assign directly, offer with an acceptance window, fall back to a pool, or auto-assign after a timeout - with availability, working hours and capacity caps applied throughout, and an audit log showing every hop. Changing from push to pull for one team is a settings change, not a rebuild, which matters more than it sounds: the value of these models is only visible once you've tried both.

How to compare them with data.

If you're genuinely undecided, run both - different teams or different lead segments - and compare four things:

‍

1. Time to first touch, split by lead quality band. Aggregate averages hide the cherry-picking effect entirely. You need to see whether your weakest-fit leads are being touched at all.
2. Queue or assignment age at p50 and p90. The gap between them is the whole story.
3. Distribution variance across reps. How evenly work landed. Wide variance under pull is expected; wide variance under push means your rules have a bug.
4. Conversion by model, controlled for lead source. The one that matters, and the one people skip because it's harder to isolate.

‍

Run it for a full sales cycle before you decide. Anything shorter measures novelty.

The bottom line: push for speed, pull for judgement, hybrid for both.

Push routing optimises for the lead - every record gets an owner instantly, and fairness is guaranteed by design. Pull routing optimises for the rep - autonomy, choice, and genuine engagement with the leads they claim. Both fail in predictable, well-documented ways, and both failures are fixed by the same move: adding the other model as a backstop. Decide which one is your default, add a timeout in the other direction, and measure queue age at the 90th percentile rather than the average. That single number will tell you more about your routing than any dashboard you currently have.

Fancy giving Distribution Engine a try?

You can trial Distribution Engine for free, or get in touch if you'd prefer to chat.

Related articles

• Salesforce Omni-Channel Lead Routing: Using Queue-Based Assignment for Real-Time Distribution
• How to Assign Leads in Salesforce (Manual, Rules and Automated)
• Salesforce Round Robin Assignment: How to Set It Up and Scale It
• Speed to Lead: Why Response Time Decides Your Pipeline (And How to Fix It)

Frequently asked questions.

What is the difference between push and pull lead routing?

Push routing automatically assigns each lead to a specific owner at the moment it's created, using rules such as round robin, territory or account ownership. Pull routing places leads in a shared queue with no owner, and reps claim the ones they want to work. Push guarantees fast, fair assignment; pull gives reps autonomy but risks attractive leads being taken while awkward ones sit unclaimed.

Is push or pull routing better for speed to lead?

Push is better for speed to lead. A pushed lead has a named owner within milliseconds, whereas a pulled lead has no owner until a rep chooses to claim it - which may be minutes or, for less appealing leads, never. If response time is your main constraint, run push as the default and add a claim window so unactioned leads re-route automatically.

How do you stop reps cherry-picking leads from a queue?

Set a claim window with automatic assignment at the end of it, so no lead can sit unclaimed indefinitely. Then monitor queue age at the 90th percentile rather than the average, and track claim rate broken down by lead segment - cherry-picking is invisible in aggregate figures and obvious as soon as you split by lead quality.

Can Salesforce do both push and pull routing?

Yes. Push is built with Lead Assignment Rules or Flow; pull is built with Queues and rep-initiated ownership changes. Omni-Channel sits between the two, pushing work to available users who then accept it. Combining them into a true hybrid - assign, then re-route on timeout - requires custom Flow with timestamp tracking natively, or a routing tool that handles acceptance windows and fallbacks as configuration.

What is a hybrid routing model?

A hybrid routing model combines both approaches so that each covers the other's weakness. The two common patterns are push with a claim window (assigned immediately, returned to the pool if not actioned within a set time) and pull with timed auto-assign (freely claimable for a window, then automatically assigned). Most teams operating at scale end up on one of these rather than a pure model.

‍