Territory-based assignment with Plauti (routing + overlaps)

June 25, 2026
Reading time: 4 minutes

Regional sales teams have a geography problem. Leads from Texas should go to Southwest reps. Leads from Germany should go to the DACH team. It sounds simple; in practice, Salesforce's native assignment tools make it surprisingly painful to maintain.

The good news: Plauti Assign was built with exactly this use case in mind. Here's a practical walkthrough of how territory logic works in Plauti Assign, how to handle the tricky part (overlapping territories), and a few admin pitfalls worth avoiding.

How territory logic maps to Plauti Assign

Plauti Assign organizes routing around a core concept called a MatchGroup. A MatchGroup answers two questions: which records should be routed here (Match Rules), and who should receive them (Assignees).

For territory-based assignment, your Match Rules are geographic filters. You're essentially telling Plauti Assign: "If the Lead's State field contains Texas, Oklahoma, or New Mexico, route it to this group." The Match Groups configuration supports text, picklist, formula, and other Salesforce field types, so you can model territories using whatever geographic data you already store on the record.

Once a record matches the group, distribution within that territory follows your chosen operational mode: Round Robin for equal spread, Load Balanced for capacity-aware routing, or Distance mode if you want the nearest available rep to get the record.

Territory based assignment with plauti

Step-by-step: Setting up a territory MatchGroup

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

  1. Open Plauti Assign via the App Launcher and go to the Assign Setup tab.
  2. Create a new MatchGroup. 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 in users by Role or Division if the team changes frequently.
  6. Set the Operational Mode to Round Robin (or Load Balanced 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 precedence

This is where things get interesting. Real sales structures rarely map cleanly onto mutually exclusive geographies. You might have a national accounts team that handles any lead from a Fortune 500, regardless of state. Or an enterprise overlay team that covers the whole EMEA region, but only for companies above a certain size.

Plauti Assign handles this with the Priority field on each MatchGroup. Priority is a number: 1 is highest. When a record matches multiple MatchGroups, the one with the lowest Priority number wins.

So, for the Fortune 500 overlay example:

  • National Accounts MatchGroup: Match Rule = Company Size EQUALS Enterprise, Priority = 1
  • Southwest US MatchGroup: Match Rule = State CONTAINS Texas..., Priority = 2

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

For cases where you want a true fallback (all Southwest reps are at capacity), MatchGroup Priority and Overflow lets you designate an overflow MatchGroup. When the primary group is full, the record automatically moves to the next group in the sequence rather than sitting unassigned.

A simple automation pattern (no Apex required)

For most territory setups, no code is needed. Plauti Assign triggers on record creation or update natively. But if you want to re-route a lead when a field changes, for example, when a lead's Country is updated after enrichment, you can trigger Plauti Assign to process records on update by configuring the object to re-process when specific fields change.

For more complex scenarios, the Plugin operational mode lets you write an Apex class implementing srrPluginInterface. This is the right path if your territory logic lives in an external lookup table, a custom hierarchy object, or a Salesforce Territory Management model that you want Plauti Assign to respect. The Routing Plugin SDK docs walk through the full event lifecycle.

Admin checklist and common pitfalls

Before going live with territory routing, run through these:
  • Make Match Rules mutually exclusive where possible. Overlapping rules aren't a problem when you use Priority correctly, but ambiguous setups are harder to debug.
  • Test with records from each territory before enabling for all users

    Use the routing log to confirm which MatchGroup processed each record.

  • Set a Queue User on each MatchGroup. This is the fallback assignee when all reps are unavailable. Without it, a record may go unassigned silently.
  • Use Dynamic Assignees for large or changing teams. Adding users manually to 12 regional MatchGroups is a maintenance headache. Pulling by Role or Division means the group updates automatically when someone joins or leaves.
  • Watch for timezone issues with business hours. If your APAC reps have defined working hours and a lead arrives at 2 am their time, Plauti Assign will queue the record rather than assign it. That's the intended behavior, but admins sometimes mistake it for a routing error.

For detailed guidance on skill-based routing and language-based overlays, the support portal has dedicated configuration articles that complement the territory setup described here.

Territory-based ownership doesn't have to mean rigid, IT-dependent rules. With Plauti Assign, an admin can build, test, and adjust the full routing structure without writing a single line of Apex, and managers can update their teams in real time without raising a ticket. That's the kind of clean, scalable setup that makes a Salesforce org actually enjoyable to maintain.

Hungry for more?
View resources