---
title: "Territory Management & Realignment"
description: "After your initial territory build, the real work begins: fine-tuning boundaries, splitting oversized territories, merging underused ones, and rebalancing after team or data changes. The MCP Server provides a full set of management tools that you drive through natural language.…"
url: "https://www.easyterritory.com/documentation/ezt-mcp/territory-management-realignment/"
updated: "2026-09-29"
category: MCP Server
---

# Territory Management & Realignment

After your initial territory build, the real work begins: fine-tuning boundaries, splitting oversized territories, merging underused ones, and rebalancing after team or data changes. The MCP Server provides a full set of management tools that you drive through natural language.

## Realigning ZIP Codes Between Territories

Sometimes a few ZIP codes land in the wrong territory. Rather than rebuilding from scratch, you can move individual parts between territories using the map selection workflow.

### Map Selection Workflow

The server uses a three-step process for interactive realignment:

1. **Request selection:** The agent calls `request_part_selection` to put the map into selection mode.
2. **You select:** Click the ZIP codes you want to move on the map. The server captures your selection.
3. **Realign:** Tell the agent which territory to move the selected parts into. The agent calls the realignment tool and the map updates.

Try saying:

```
“I want to move some ZIP codes from Territory 3 to Territory 5. Open the map for selection.”
```

After you finish selecting, confirm the target territory:

```
“Move those selected ZIP codes into Territory 5.”
```

## Splitting an Oversized Territory

When one territory has too much workload, `territory_split` divides it into two smaller territories with minimal disruption to the surrounding areas. The split algorithm preserves compactness and tries to keep the two halves balanced.

Example prompt:

```
“Territory 2 is too large. Split it into two balanced territories.”
```

The agent will call `territory_split` with the territory identifier. The result is two new territories replacing the original, each with roughly half the workload. The split minimizes disruption — surrounding territories are unaffected.

## Merging Two Adjacent Territories

When two territories are underutilized (e.g., after a rep departure), `territory_merge` combines them into a single territory. The merge preserves all assigned parts and recalculates the combined workload.

Example prompt:

```
“Merge Territory 4 and Territory 7 into a single territory.”
```

The agent calls `territory_merge` with both territory identifiers. The result is one territory containing all parts from both originals. After merging, you may want to rebalance (see below) if the combined workload is too high.

## Rebalancing After Data Changes

When your account data changes — new accounts added, accounts lost, visit frequencies updated — your existing territories may no longer be balanced. `territory_rebalance` adjusts boundaries to restore balance with minimal disruption. Unlike a full rebuild, it preserves the overall structure and only moves parts that are significantly out of balance.

Example prompt:

```
“I added 200 new accounts. Rebalance the existing territories with minimal disruption.”
```

The agent calls `territory_rebalance`, which shifts parts between territories to even out the workloads while keeping changes localized. The number of territories stays the same.

## Deleting Territories

You can delete a single territory or an entire territory assignment layer (TAL):

- **Single territory:** `delete_territory` removes one territory and returns its parts to the unassigned pool.
- **Entire TAL:** `delete_tal` wipes all territories in the current assignment layer. Use this when you want to start fresh without deleting your account data.

Example prompts:

```
“Delete Territory 6 — we're reassigning that region to another team.”
“Delete all territories so I can start a new build from scratch.”
```

## Always Re-Analyze After Changes

After any management operation — split, merge, rebalance, realign, or delete — re-run the analysis to verify the result. This is a hard invariant (called I-2 in the server's internal documentation): every structural change invalidates prior analytics.

Always say:

```
“Re-analyze and load the results panel.”
```

The agent calls `analyze` followed by `load_analysis_panel`, giving you a fresh view of balance metrics, drive times, and compactness scores. Never trust analytics from before a structural change.

## Example Prompts for Every Operation

| Operation | Example Prompt |
| --- | --- |
| Realign parts | “Move the selected ZIP codes from Territory 3 to Territory 5.” |
| Split | “Split Territory 2 into two balanced territories.” |
| Merge | “Merge Territory 4 and Territory 7 into one territory.” |
| Rebalance | “Rebalance all territories with minimal disruption — I just added 200 accounts.” |
| Delete one | “Delete Territory 6.” |
| Delete all | “Delete all territories so I can start over.” |
| Re-analyze | “Re-analyze and load the results panel.” |

---

## Next Steps

- [Territory Building with AI](/documentation/ezt-mcp/territory-building-with-ai/) — How to build territories from scratch.
- [Routing & Scheduling](/documentation/ezt-mcp/routing-scheduling/) — Optimize field visits and recurring schedules.
- [MCP Server Tools Reference](/documentation/ezt-mcp/mcp-server-tools-reference/) — Full list of all 47 tools.