GoHighLevel Territory Routing: Lead Assignment (2026)
By Dr Priya Jaganathan, GoHighLevel Certified Admin · HL Growth Partner, Australia · Updated 20 September 2026 · 9 min read
Some links below are affiliate links — if you sign up through them, HL Growth Partner may earn a commission at no extra cost to you. It never changes what we recommend. Full disclosure.
GoHighLevel territory routing is the difference between a Bendigo enquiry landing with the rep who services Bendigo, and that same enquiry sitting unassigned while three people assume someone else has it.
Most Australian service businesses hit this at around the third rep. Here is the data model, the capture, the branching logic, round-robin inside a territory, and the fallbacks that stop leads disappearing.
Quick Facts
| Where territory data lives | Contact custom fields (Postcode, Territory, Region), plus tags for segmentation and smart lists. |
| Action that sets the owner | Assign to User, inside a Workflow. Sets one named user or rotates round robin across a selected group. |
| Triggers that can start routing | Form Submitted, Survey Submitted, Facebook Lead Form Submitted, Inbound Webhook, Contact Created, Opportunity Created. |
| Native postcode lookup | Does not exist. You build the map with If/Else, custom values or an external call. |
| Round-robin scope | Configured per Assign to User action, so each territory branch needs its own action. |
| Standard address fields | Address, City, State, Postal Code and Country ship on every contact record. |
| Where the logic runs | Sub-account Workflows, distributed across accounts via snapshots. |
Your routing breaks in the data model, not the workflow
Nearly every failed routing build I audit has the same root cause. The territory was never a field — it was a rule living in someone's head.
Fix that first. Create a custom field called Territory, and a second called Service Region if you need a coarser grouping like Metro Melbourne versus Regional Victoria.
The postcode is your input; the territory is your output — and both belong on the contact record. The workflow resolves the postcode to a territory, writes it back, then assigns on the field rather than re-deriving it every time.
Deciding how granular to go
Australian territories rarely map cleanly to one dimension. A Sydney plumber splits by postcode clusters; a national solar installer splits by state first, then metro or regional.
- State-level — simplest, works with one rep or branch per state. Route on the standard State field.
- Postcode range — the workhorse for metro businesses. Group 2000–2249 as Sydney Inner, 2250–2299 as Central Coast.
- Named postcode lists — when franchise agreements specify exact postcodes and ranges would be wrong.
- Suburb or locality — highest resolution, highest maintenance, most prone to typos and duplicate suburb names.
Build the map against a real source, not memory. Australia Post publishes postcode and locality data, including the duplicated suburb names that bite you when Richmond in Victoria meets Richmond in Tasmania.
Capturing location you can actually route on
Routing logic is only as good as the postcode reaching it. Three capture surfaces matter, and each fails differently.
Forms and surveys
Make postcode required, with four-digit numeric validation. A free-text suburb box alone will hand you "Nth Syd", "north sydney" and "Sydney???" inside a fortnight.
Map it to a dedicated custom field, not just the generic address block — that keeps the raw input separate from any cleaned value you write later.
Facebook and Instagram lead ads
Meta's autofill is inconsistent and people type whatever they like. Use a short-answer numeric question with clear helper text, and expect junk.
Your Facebook lead ads integration must write to the same custom field your forms use. If ads and forms populate different fields, your If/Else tree silently misses half your volume.
Inbound calls and chat
Calls arrive with no postcode. LC Phone or Twilio gives you a number, and an area code is a weak proxy — mobiles tell you nothing.
Route unassigned calls to a central queue, capture the postcode in conversation, then fire the routing workflow retrospectively off a tag. Conversation AI can ask for a postcode in chat before handover, which is often the cleanest capture of the three.
If/Else branches vs a lookup table: picking your HighLevel lead routing engine
This decision determines how painful year two will be. The right approach depends on how many territories you have and how often the boundaries move.
| Approach | Best when | Maintenance | Main limitation |
|---|---|---|---|
| If/Else on State or postcode range | Up to roughly a dozen stable territories | Low at first, rises with every branch | Each boundary change is a workflow edit and a re-test |
| Tag-driven branching | You already segment by tag and want smart lists to match routing | Moderate — tag sprawl needs governance | Tags are easy to create, hard to retire; naming drift kills it |
| Outbound webhook to a sheet or small API | Dozens of postcodes, or boundaries that move quarterly | Low — a non-technical person edits a spreadsheet | External dependency and latency; needs its own failure path |
For most Australian SMEs with four to ten territories, plain If/Else conditions in GoHighLevel workflows are correct. Use greater-than and less-than operators so a range is one condition, not fifty.
Past roughly fifteen territories, move the map out of the workflow and into a spreadsheet operations owns. The workflow then does one job: send the postcode, receive a territory and owner, write them to the contact.
Round-robin inside a territory, without leaking across borders
The mistake is predictable. Someone builds one round-robin Assign to User at the top of the workflow, adds territory branches underneath, and every rep gets leads from every postcode.
Round robin lives inside each Assign to User action. That means one Assign to User per territory branch, with only that territory's reps in the rotation — four territories of three reps is four actions, not one.
Keep the split set to equal unless you have a deliberate reason to weight it. Then decide whether reassignment may overwrite an existing owner; for returning enquiries you almost always want the original owner kept.
Handling leave and uneven capacity
Weighting handles a rep with more capacity. HighLevel will not skip someone on leave, so gate a second action behind an If/Else on a "Rep Available" custom value, or pull them from the rotation and note why.
Not on HighLevel yet? Start with a free 30-day trial here — long enough to build everything in this guide before you pay a cent.
Fallbacks: unmatched postcodes, after hours and public holidays
Fallback handling is where amateur builds are exposed. Every branch tree needs a final Else, and that Else must do something useful.
| Scenario | How you detect it | What the workflow does |
|---|---|---|
| Postcode missing | If/Else: postcode is empty | Tag routing-no-postcode, assign to central intake, SMS asking for the suburb |
| Valid but outside all territories | Falls through to the final Else | Tag routing-out-of-area, assign to a manager, notify for a manual call |
| Malformed input | Length or numeric check before branching | Same path as a missing postcode — never reaches a territory branch |
| Outside business hours | Wait step resuming on the next window | Assign immediately, but hold the rep alert until opening time |
| Public holiday | Custom value holding the state's holiday list | Auto-reply, delay alerts, escalate anything untouched next morning |
State-specific holidays are a genuinely Australian problem. Melbourne Cup Day is a Victorian public holiday and an ordinary Tuesday in Perth, so one national list routes Perth leads into a black hole for a day.
Timing matters for compliance too. Automated SMS must respect consent, identification and unsubscribe rules — the ACMA guidance on the Spam Act applies whichever territory the lead falls into.
Telling the assigned rep, and making it stick
Assignment without notification is just a database change. The rep needs to know within a minute, with enough detail to act.
- Include suburb and postcode in the notification body, not just name and phone.
- Send to the assigned user dynamically rather than hard-coding addresses per branch.
- Use email plus SMS for high-value territories, accepting that staff alerts still consume message credits.
- Add a Wait step of ten to fifteen minutes, then check whether the opportunity moved; if not, escalate to the manager.
Build the alert mechanics once and reuse them. Our guide to internal team notifications covers the dynamic-recipient pattern that lets one action serve every territory.
Reporting that shows which territories actually work
Track three things per territory: volume in, speed to first contact, and conversion to won. High volume with slow first contact is a staffing problem; low volume with high conversion is an ad-spend problem.
Build smart lists filtered by the Territory field and by owner, then surface them on a dashboard. Pair that with GoHighLevel dashboard reporting so the weekly sales meeting runs off one screen.
Keep a separate view for the out-of-area tag. Steady growth there means a gap in the map, or real demand worth opening.
Multi-location and franchise: one sub-account or many?
Franchise networks face a structural choice before any routing logic gets built. One sub-account with territory fields, or one sub-account per franchisee with a router in front.
A single sub-account keeps reporting unified, but everyone sees every contact unless permissions are locked down hard. Separate sub-accounts give clean boundaries at the cost of a cross-account handoff.
If franchisees own their leads contractually, use separate sub-accounts. The extra plumbing is cheaper than the trust problem.
Either way, standardise field names and workflow structure before you distribute anything. The multi-location and franchise setup approach we use puts the routing skeleton in a snapshot, so each new location inherits identical logic with only the postcode map and user list to change.
Common mistakes to avoid
- No final Else branch. Unexpected postcodes exit the workflow unassigned and nobody finds out until the monthly review.
- One round-robin above the territory branches. It distributes evenly across all reps and ignores geography entirely — the most common build error I see.
- Forms and lead ads writing to different fields. Half your volume bypasses the logic while you blame the workflow.
- Overlapping postcode ranges. If 3000–3200 and 3150–3300 both exist, the first match wins and one territory quietly starves.
- Territory stored only as a tag. Tags filter well and compare badly; keep both, governed by a deliberate tag structure.
- Testing with one contact. Run a test per territory plus three deliberate failures — empty, malformed, out-of-area — before going live.
Get your territory map routing correctly
If leads land with the wrong rep, arrive late, or sit unassigned overnight, the fix is usually two hours of data-model work followed by one carefully branched workflow. We build it with you and hand over the documentation.
Or if you just need the software first: grab the 30-day HighLevel trial and book us when you're ready to scale it.
Frequently asked questions
Does GoHighLevel have a built-in postcode-to-territory lookup?
No. There is no native postcode lookup table in GoHighLevel. You build the mapping yourself using If/Else conditions on the postcode field, custom values holding lists, or an outbound webhook to an external sheet or API that returns the territory.
Can I run round-robin assignment within a single territory?
Yes. Round robin is configured inside each Assign to User action, so you place one action inside each territory branch and include only that territory's reps in the rotation. A single round-robin action sitting above your branches will distribute across all reps regardless of location.
What happens to a lead with a postcode I have not mapped?
It falls through to your final Else branch. Tag it as out-of-area, assign it to a manager or central intake user, and trigger an internal notification so a human decides whether to service it or refer it out.
How do I capture postcode from Facebook lead ads reliably?
Add a short-answer postcode question to the lead form with clear helper text, and map it to exactly the same custom field your website forms use. Expect some junk input, so validate field length in the workflow before branching on it.
Should I route on state, postcode or suburb?
Use the coarsest level that still reaches the right person. State works when you have one rep or branch per state, postcode ranges suit metro businesses, and suburb-level routing is only worth the maintenance when franchise agreements demand that precision.
How do I stop leads being assigned outside business hours?
Assign the owner immediately so the contact always has an owner, then hold the notification behind a Wait step that resumes at the next business window. Check state-specific public holidays separately, because a national holiday list will misfire for at least one state every year.
Is one sub-account or many better for a franchise network?
Use one sub-account when you need unified reporting and franchisees are comfortable sharing a database with tight permissions. Use separate sub-accounts when leads are contractually owned by each franchisee, and route between them with an inbound webhook that creates the contact in the correct location.
Related Articles on HL Growth Partner
Building the workflow logic
- Wait steps and goal events, configured properly
- Troubleshooting workflow errors before they cost you leads
- Workflow folders and naming conventions that scale
Getting the data right
- Importing contacts with clean CSV field mapping
- Custom objects and data modelling in HighLevel
- A tag strategy that does not turn into sprawl
