Knowing you need lead routing and actually building it properly are two different problems. The first is a five-minute conversation. The second is where most setups quietly go wrong - a workflow that looks right in testing but leaves real leads unassigned, duplicated, or sitting with someone who's on leave.

This is the build guide. Not the "why it matters" version - the actual mechanics: how HubSpot's rotation logic works, how to branch it around your real sales structure, and how to make sure nothing falls through when a rule doesn't match. Work through it in order and you'll end with a routing system that holds up in the messy real world, not just the demo.

_ (10)-1

What You Need Before You Start

Lead rotation and routing workflows are built using HubSpot's Workflows tool, which requires Sales Hub or Service Hub Professional or Enterprise. If you're on Starter or below, native workflow-based routing isn't available to you - you'd be looking at a manual process or a marketplace app instead.

You'll also need paid seats set up correctly. Any user you want included in a rotation needs the relevant paid seat - a Sales seat for contact and deal rotation, a Service seat for ticket and conversation rotation. Users without one won't appear as an option in the routing action, and deactivated users show with a red border and get excluded automatically.

One more prerequisite worth sorting first: your data. Routing logic reads from properties - source, territory, company size, product interest, lifecycle stage. If those fields aren't populated consistently, your routing will run perfectly and still send leads to the wrong place, because it's working from bad inputs. Fix your data hygiene before you build the workflow, not after.

 

Step 1: Build the Enrolment Trigger

Every routing workflow starts with a contact-based (or ticket-based, or conversation-based) workflow, and the first real decision is what triggers a record into it.

Go to Automation > Workflows > Create workflow, choose a contact-based workflow, and set your starting trigger. Common triggers for lead routing:

  • Form submission - the most common starting point for inbound leads.
  • Contact owner is unknown - catches any contact that doesn't yet have an owner, regardless of how they entered the system.
  • List membership - if you manage entry via an active list with its own filtering logic.

If you're worried about people submitting the same form multiple times and wanting to be rotated again, decide your re-enrolment setting deliberately - allow re-enrolment if repeat submissions should re-trigger routing, and switch it off if a contact who already has an owner should never be reassigned by this workflow.

 

Step 2: Add Branching Logic for Real Routing Rules

A single flat rotation across your whole team is rarely what a real business needs - you probably want leads split by territory, product line, deal size, or company type. This is where if/then branches come in.

After your trigger, add branching logic based on the properties that actually determine ownership in your business. For example:

  • Branch by region or territory, so a lead in one area goes to the rep who covers it.
  • Branch by company size or employee count, so an enterprise-sized company routes to a senior rep rather than an SMB-focused one.
  • Branch by product interest or lifecycle stage, so a support-related enquiry doesn't land in your new-business queue.
  • Branch by customer status, so an existing customer asking about an upgrade goes to expansion or customer success rather than new-business sales.

Each branch then leads to its own rotation action, meaning different segments of your leads rotate across entirely different pools of reps. This is the actual mechanism that lets HubSpot reflect how your sales team is genuinely structured, rather than treating every lead identically.

 

Step 3: Add the Rotate Record to Owner Action

Inside each branch, this is the action that actually assigns ownership. Here's exactly how it behaves, because the mechanics matter.

Add the action. Click the + icon after your branch, and select Rotate record to owner from the assignment actions. Choose which property it's rotating - typically Contact owner, though it can be a custom HubSpot user property if you're tracking a separate role (a BDR, for instance, alongside the main owner).

How the rotation actually distributes. HubSpot tracks a separate assignment count for each individual rotate action in your workflow. When the workflow first goes live, every included owner starts at zero. The first contact to reach the action is assigned to one of them at random (since they're all tied at zero); from then on, each new contact goes to whichever included owner currently has the lowest count for that specific action. It's an even, sequential distribution - not based on how many leads someone owns across your whole account, just within that one action.

Only unowned records get assigned. This is an important, easy-to-miss detail: the Rotate record to owner action only assigns records that don't already have an owner set on the relevant property. If a record already has one, the action won't touch it - you'd need to clear the existing value first (the Clear property value action does this in bulk) before it'll be eligible for rotation again.

Assigning more than one role at once. If you want both a primary owner and a separate role assigned - say, a sales rep and a BDR - you can add the Rotate record to owner action twice in the same workflow, once for each property, and HubSpot rotates each independently.

Seats are enforced automatically. Only users with the appropriate paid seat can be included, and HubSpot won't assign to anyone who's been deactivated or lost their seat.

Im In Meme at Jacquelinepugh

Step 4: Handle Ticket and Conversation Routing (If Relevant)

If your routing also needs to cover support tickets or live chat conversations, not just contacts, the same Rotate record to owner action applies but with a few extra behaviours worth knowing.

For tickets: you can rotate based on a straightforward balanced distribution, or route according to real-time capacity - the number of open tickets a user currently has - so busier reps get fewer new assignments. There's also a beta option, available to Super Admins, for rotating based on user availability rather than a flat rule. Teams used for ticket rotation need at least one member with a paid sales or service seat, and only main team members (not additional/extra members) are eligible.

For conversations (live chat, for example): the same action can move a conversation to a different inbox and reassign it, and it respects who currently has access to that inbox. One specific behaviour worth knowing: changing the owner on a closed conversation will reopen it - so if that's not what you want, exclude closed conversations from your enrolment criteria. If you're using rules-based bots, it's also recommended to exclude bot-based chatflows from the workflow and instead handle that routing directly inside the chatflow's own "send to team member" action.

 

Step 5: Build the Fallback - Don't Skip This

This is the step that separates a routing system that holds up from one that quietly leaks leads. Every routing workflow needs a defined fallback for when a condition isn't met or a rotation can't be completed.

Set a fallback owner or queue. For ticket and conversation rotation specifically, HubSpot lets you configure this directly: choose a fallback of specific users or teams, or no owner (which deliberately unassigns rather than leaving a stale owner in place). This fallback fires automatically if the primary rule doesn't find a match, or if the assigned owner doesn't have the right seat.

Design your own fallback for contact-based workflows. Contact routing doesn't have quite the same built-in fallback selector as ticket and conversation routing, so build it deliberately: add a final branch that catches anything not matched by your earlier criteria, and route it to a default owner, a review queue, or a specific person whose job includes catching the exceptions. Pair this with a task, so a real person knows an unmatched lead needs manual attention rather than it silently sitting unassigned.

Never let "no match" mean "no action." An unassigned lead with no fallback is the single most common way routing systems fail quietly - the workflow runs, nothing throws an error, and the lead simply never gets to anyone.

 

Step 6: Add the Action, Not Just the Assignment

Assigning an owner is only half the job. Pair it with what should happen next, in the same workflow:

  • Create a task for the new owner, with a clear deadline, so the assignment comes with an explicit next step rather than just appearing on their dashboard
  • Send an internal notification - email or a connected tool like Slack - so the rep knows immediately, not whenever they next check HubSpot
  • Create a deal, if the enrolment criteria indicates a genuine sales opportunity, so the lead moves into your pipeline rather than sitting as an unconverted contact

This is what turns "the lead has an owner" into "the lead is actually being worked" - the gap between those two things is where a lot of routing value quietly gets lost.

 

Step 7: Test It Properly Before Going Live

Before switching a routing workflow on for real leads, test it against the messy scenarios, not just the clean one.

Test a lead with missing data - no region, no company size - and confirm it hits your fallback rather than erroring silently. Test a lead whose contact already has an owner, to confirm the rotate action correctly skips reassignment. Test a duplicate scenario, since duplicate contacts or companies are one of the most common causes of routing confusion in practice. If you have access to a sandbox environment, this is exactly the sort of workflow worth testing there first, particularly if the workflow will touch owner fields, deal creation, or lifecycle stages that other systems depend on.

Turn the workflow on only once you've seen it handle the edge cases correctly, not just the happy path.

 

Step 8: Monitor What You Built

A routing workflow isn't "set and forget." Once live, check in on it - particularly in the first few weeks, and then on a regular cadence after that.

Look at how many contacts are landing in your fallback (a high number suggests your branching criteria don't match reality as well as you thought). Check that rotation is actually distributing evenly across the reps you expected. And revisit the workflow whenever your sales structure changes - a new hire, a changed territory, a discontinued product line - because a routing workflow built around last year's team will start silently misrouting the moment this year's team looks different.

eggsacly meme

Wrapping Up

Good lead routing in HubSpot isn't one clever workflow, it's a stack of deliberate decisions: the right trigger, branches that reflect how your team is actually structured, a rotation action that's genuinely feeding from clean, unowned data, a fallback that catches everything the rules don't, and an action attached to every assignment so ownership turns into follow-up. Skip any one of those and you get a workflow that looks fine in the builder and quietly fails in production.

Build it properly, test the messy cases, and check on it as your team changes - and lead routing stops being a thing that occasionally embarrasses you in a pipeline review, and starts being infrastructure you don't have to think about.

Want your HubSpot lead routing built properly, and testing done before it touches real leads? Give us a shout.

Stay ahead of the latest HubSpot updates by joining our community and catching our latest HubSpot tutorials on YouTube.

Happy HubSpotting!