Territory-Based Assignment in Salesforce: Rules for Overlaps

Regional sales teams have a geography problem. Leads from Texas should reach the Southwest team. Leads from Germany should reach the DACH team. Salesforce's native assignment rules make that surprisingly hard to keep running once territories change or overlap.

This is a route-and-assign problem: once your data is clean, the next job is getting each record to the right rep, in real time. Here's how territory-based routing works in Plauti, how overlapping territories get resolved, and where admins usually trip up.

How territory routing works in Plauti

Plauti organizes routing around the match group: a rule set that answers two questions. Which records qualify (match rules), and who should receive them (assignees).

For territory-based assignment, your match rules are geographic filters. You're telling Plauti: if the Lead's State field contains Texas, Oklahoma, or New Mexico, route it to this group. Match group rules support text, picklist, formula, and other Salesforce field types, so you can model territories against whatever geographic data already lives on the record. The match group configuration documentation covers the full set of supported field types.

Once a record matches a group, distribution inside that territory follows the operational mode you pick: round robin for equal spread, load balancing for capacity-aware routing, or distance-based routing to send the record to the nearest available rep.

Set up a territory match group

Here's the basic pattern for a US-region example.

1. Open Plauti from the App Launcher and go to its routing setup.
2. Create a new match group and name it clearly, for example Leads - Southwest US.
3. Set the object to Lead and the assignment field to OwnerId.
4. Under match rules, add a condition: State/Province CONTAINS Texas, Oklahoma, New Mexico, Arizona.
5. Add your Southwest reps as assignees. Use dynamic assignees to pull users in by role or division if the team changes often.
6. Set the operational mode to round robin, or load balancing if workloads vary.
7. Save and activate.

Repeat for each region. Within a few minutes you'll have a DACH group, a Nordics group, a UK group, and so on, each with its own rep pool and its own capacity settings.

Overlapping territories and priority

Real sales structures rarely map onto mutually exclusive geographies. A national accounts team might handle any Fortune 500 lead regardless of state. An enterprise overlay team might cover all of EMEA, but only for companies above a certain size.

Plauti resolves this with a priority number on each match group. Priority 1 is highest. When a record matches more than one group, the lowest number wins.

Take the Fortune 500 overlay example:

• National Accounts match group: match rule = Company Size EQUALS Enterprise, priority 1.
• Southwest US match group: match rule = State CONTAINS Texas..., priority 2.

A large enterprise lead from Texas matches both groups. Priority 1 wins, so it goes to the National Accounts team. A small-business lead from Texas only matches the Southwest group and routes there as usual.

For a true fallback, when every Southwest rep is at capacity, priority and overflow configuration lets you designate an overflow match group. When the primary group is full, the record moves automatically to the next group in the sequence instead of sitting unassigned.

Automate routing without Apex

Most territory setups need no code. Plauti triggers on record creation or update natively. If you want to re-route a lead when a field changes, for example when a Lead's Country updates after enrichment, you can configure the object in routing setup to re-process records whenever specific fields change.

For more complex scenarios, the plugin operational mode lets you write an Apex class that implements srrPluginInterface. Use this when your territory logic lives in an external lookup table, a custom hierarchy object, or a Salesforce Territory Management model that you want Plauti to respect. The Routing Plugin SDK documentation walks through the full event lifecycle.

Admin checklist before going live

Run through these before turning on territory routing for the full team.

• Make match rules mutually exclusive where possible. Overlap isn't a problem once priority is set correctly, but an ambiguous setup is harder to debug later.
• Test with records from each territory before enabling for everyone. The routing log shows which match group processed each record.
• Use dynamic assignees for large or changing teams. Adding users manually across a dozen regional match groups is a maintenance chore. Pulling by role or division keeps every group current when someone joins or leaves.
• Watch for time zone issues on business hours. If your APAC reps have set working hours and a lead arrives at 2am their time, Plauti queues the record instead of assigning it immediately. That's expected behavior, not a routing error, though it's easy to mistake for one.

For skill-based and language-based routing, the support portal's advanced routing articles cover setups that build on the territory pattern here.

Territory-based ownership doesn't need rigid, IT-dependent rules. An admin can build, test, and adjust the full routing structure without writing Apex, and a manager can update their team in real time without filing a ticket.