Build Salesforce Round-Robin Lead Assignment With AI

Salesforce round-robin lead assignment is the most requested thing Salesforce doesn’t ship. There’s no checkbox for it. As Salesforce Ben puts it plainly, “Salesforce doesn’t offer a direct built-in round robin feature, but there are several ways to implement it.” So every ops team builds one, and almost every team builds the same fragile version: an auto-number field, a MOD formula, and a row in the assignment rules for each rep.

That version works until the team changes. Which is to say, it works until Tuesday.

This is a step-by-step build for a round robin that survives contact with a real sales team — one that knows who’s at capacity, who’s on PTO, and why any given lead landed where it did. The position I’ll defend the whole way down: round robin is not a distribution problem, it’s a roster problem. Build the roster as data and the distribution becomes trivial. Encode the roster in a formula and you have signed up to maintain that formula forever.

Why the MOD-formula version cracks

The classic recipe is elegant on a whiteboard. Give the Lead an auto-number field, run MOD(auto_number, 4) to get 0–3, and write four assignment-rule entries — one per rep — keyed to the result.

Then someone joins. Now it’s MOD(n, 5), every rule entry shifts, and the historical assignments no longer mean what they meant. Salesforce Ben names this cost directly: “If you ever need to add new members to your round robin group, you’ll have to manually update your formula.”

It gets worse in ways the whiteboard doesn’t show. A MOD counter distributes by arrival order, not by availability — it will keep handing leads to someone who is out for two weeks, and it has no idea that one rep is sitting on forty open leads while another has six. And you can’t quietly clean up afterward, because a user who appears in your assignment rules can’t be deactivated until you take them out of the rules first.

That’s the real failure mode. Not unfairness — invisible unfairness, discovered a month later when someone finally counts.

Let the rules do the matching. Build the choosing.

The architecture that holds up splits the job in two, and it’s worth being precise about the split because it’s what makes the build small.

Salesforce assignment rules are genuinely good at matching: given a lead, decide which bucket it belongs to. They evaluate entries in order and the first match wins — “Lead Assignment Criteria are going to be evaluated in the order they appear, so it’s critically important to get it right” — and they can assign to a user or to a queue.

So let them match, and have them assign to a queue per segment, never to a person. Enterprise inbound goes to the Enterprise queue. West region goes to the West queue. That’s one rule entry per segment instead of one per rep, and it stops changing every time headcount does.

Then build the second half — the part rules can’t express — as the thing that picks a human out of the queue. That’s the whole build. Everything below is that second half.

Step 1: Write the fairness rule down before you build anything

Say out loud what “fair” means at your company, because it isn’t the same everywhere and the build is different for each answer.

Fair might mean equal counts — everybody gets the same number of leads. It might mean equal opportunity — weighted so your two senior reps take a bigger share. It might mean equal load — nobody gets a new lead while they have more than twenty untouched ones. Most teams say “round robin” and mean the third one.

Write it as a sentence with its exceptions attached: deal out leads in the segment to the eligible rep who has gone longest without one, where eligible means active, not on PTO, inside working hours, and under their open-lead cap.

That sentence is the spec. If you can’t write it, you’re not ready to build — and this is the step where most round-robin projects actually fail, long before anyone opens Setup.

Step 2: Make the roster a record, not a formula

Create a custom object — call it Routing_Member__c. One record per rep per segment, with:

• User__c — lookup to the User
• Segment__c — matches the queue from your assignment rules
• Active__c — checkbox
• Weight__c — number, default 1 (a 2 takes roughly twice the volume)
• Open_Lead_Cap__c — number, blank means no cap
• Last_Assigned__c — datetime, stamped on every assignment
• Unavailable_Until__c — date, for PTO

Every future change to the team is now a record edit that a sales manager can make, not a formula edit that needs an admin and a deploy. That is the entire point of the object, and it’s why this version doesn’t rot.

Step 3: Pick by least-recently-assigned, not by counter

Here’s the trick that makes the rest simple. Don’t keep a pointer to “whose turn is it.” Instead, ask: of the eligible members in this segment, who has the oldest Last_Assigned__c? Give them the lead and stamp the field.

Least-recently-assigned is self-healing in a way a counter never is. Add a rep mid-quarter and their empty Last_Assigned__c sorts first, so they catch up automatically. Deactivate someone and they simply stop appearing in the eligible set — no renumbering, no formula edit, no orphaned rule entry blocking their deactivation. Weighting drops in cleanly too: instead of the raw timestamp, sort by how long they’ve waited divided by their weight, so a weight-2 rep comes back around twice as fast.

Eligibility is one filter: Active__c true, Segment__c matches, Unavailable_Until__c blank or in the past, and — if a cap is set — their current open-lead count below it.

Step 4: Decide what happens when nobody is eligible

This is the step teams skip, and it’s the one that generates the 6 p.m. Slack message asking why a lead has been sitting unowned since lunch.

Everyone is capped, or it’s 2 a.m., or the whole segment is at an offsite. Decide the fallback now and write it into the spec: the lead stays in the queue with a flag, and a scheduled job retries it every fifteen minutes. Or it overflows to a named backup segment. Or caps are advisory after thirty minutes of waiting and the oldest-waiting rep takes it anyway.

Any of those is defensible. What’s not defensible is silence — a lead with no owner and nothing watching it. Whatever you choose, the rule is: a lead never comes out the other side unassigned.

Step 5: Record why, on the lead itself

Add one more field to the Lead: Assignment_Reason__c, a text field the routing writes on every assignment.

"Round robin — West queue, least-recent (14 Aug 09:12), weight 1, 6 open leads"

Nobody asks for this field and everybody needs it. The first week the build is live, someone will insist routing is broken. With a reason on the record, that conversation takes ten seconds and ends in agreement. Without it, you’re reconstructing the state of a roster as it was on a Tuesday two weeks ago, and you’ll never fully prove your case.

It also gives you something to sort and count. “Show me every lead assigned by overflow last month” is a report you can actually run, and it’s usually the report that tells you the caps are set wrong.

Step 6: Handle the burst, or it will double-assign

One detail your AI should get right, and it’s worth knowing enough to check: when ten leads arrive in the same second — a webinar list, a form spike, an integration batch — parallel transactions can each read the roster before any of them writes, and all ten land on the same person.

The fix is a locked read of the roster rows inside the transaction that assigns (FOR UPDATE on the member query), so the picks serialize instead of racing. Ask for it explicitly, then test it explicitly: insert 50 leads at once in a sandbox and count the distribution. If one rep got 50 and everyone else got zero, that’s this bug, and it’s the single most common defect in a homegrown round robin.

Step 7: Test it against a week you’ve already lived

Don’t test with invented leads. Take last week’s real inbound in a sandbox — you already know how those should have been distributed, because you lived through it and you remember the two that went wrong.

Replay them through the new routing and compare. You’re looking for three things: did the counts come out roughly even, did the two known-bad ones land correctly this time, and did anything hit the fallback path. If the fallback fired more than a couple of times, your caps are too tight — fix the data, not the code.

Then deploy the ordinary way: sandbox first, tests required, production after it passes. This is a routing change, so schedule it for a quiet hour and watch the first twenty leads land with the reason field visible. Twenty is enough to know.

What this used to cost, and what changed

None of the above is exotic. It’s a custom object, a trigger with a locked query, a scheduled retry, and a text field. An experienced Salesforce developer builds it in a couple of days.

The problem was never difficulty — it was the shape of the ask. “Two days of developer time” is a request that has to be scoped, quoted, queued, and explained to someone who controls a budget, for a build whose payoff is “leads get distributed slightly more fairly.” Against a backlog of revenue-critical work it loses every time, which is why so many teams are still running the MOD formula from 2019 and reassigning by hand every Monday. (Here’s the honest math on what Salesforce developer time actually costs.)

What’s changed is who can do the building. With Sentinel connecting your AI to your org, the spec sentence from Step 1 is the request. You describe the routing policy, the exceptions, the fallback and the reason field; your AI builds the object, writes the trigger and its tests, deploys to sandbox, and comes back with results you can read. The two-day build becomes an afternoon of conversation and review, at $500/month per Sentinel plus a one-time $2,500 onboarding on your first one — and the ask stops needing a business case.

To be clear about what that does and doesn’t get you: nothing here stops you from deploying a routing rule that’s wrong. Describe your caps badly and you’ll get badly capped routing — deployed accurately, logged completely, and reversible. Every change is visible and every deploy is recoverable, which is a different promise than “safe,” and the honest one. (The full mechanism, if you want it.) ORG Endgame isn’t affiliated with Salesforce; Sentinel connects to your org through Salesforce’s own supported APIs.

Start with the reassignment you do every Monday

If you want a way in, don’t start with the whole routing policy. Start with the manual correction you already make every week.

Most ops leads have one: the reassignment they do every Monday morning because the rules put leads somewhere obviously wrong, and it’s faster to fix it by hand than to explain it to anyone. That correction is a rule you’ve already written and already tested — you’ve just been executing it with a mouse instead of putting it somewhere the org can read.

Build that one. Watch it run for a week. Then look at the rest of the routing differently, because the exceptions your assignment rules can’t express are no longer the reason to leave it alone — and neither is the rest of the backlog you’ve been rebuilding by hand.

Get your Sentinel running — onboarding included.