# Boundary Hierarchy

## **Overview**

Governments often manage multiple **boundary hierarchies**, such as:

* **Administrative** (for governance),
* **Revenue** (for taxation),
* **Service Delivery** (for operational reporting).

These hierarchies help structure geographical regions for **data capture, reporting, and accountability**.

## **Key Concepts**

Refer to the [Boundary (v2) service documentation ](https://docs.digit.org/complaints-management/deploy/configure/boundary)to understand how to create boundaries in DIGIT

<table><thead><tr><th width="223.28125">Concept</th><th>Description</th></tr></thead><tbody><tr><td><strong>Boundary Hierarchy</strong></td><td>A named structure (e.g., <em>Admin</em>, <em>Revenue</em>, <em>Tax</em>) consisting of multiple nested boundary levels.</td></tr><tr><td><strong>Boundary Level</strong></td><td>A unit of division within a hierarchy (e.g., <em>City</em>, <em>Ward</em>). Has a <strong>code</strong>, <strong>name</strong>, and <strong>parent-child relationship</strong>.</td></tr><tr><td><strong>Boundary Code</strong></td><td>Unique identifier for a boundary unit, usually used to tag a complaint or a user.</td></tr><tr><td><strong>Leaf Node Tagging</strong></td><td>Complaints are typically tagged to the <strong>lowest level</strong> (leaf node), allowing inference of the entire path up the hierarchy.</td></tr><tr><td><strong>Customizable</strong></td><td>Each implementation (like CCRS) can define its own hierarchy and levels based on reporting needs.</td></tr></tbody></table>

## **Default Boundary Setup in CMS**

Each tenant can define a boundary hierarchy within itself. For example, the default setup in CMS looks like this:

```
Country → State → City → Zone → Ward → Locality
Example: India → Karnataka → Bangalore → Bangalore South → Koramangala → Block3
```

* Complaints are tagged to **Locality Code** (e.g., `Block3`).
* This allows aggregation at any level — Ward, Zone, City, State, etc.

## **Best Practices**

Design boundary hierarchies based on:

* **KPIs that need to be tracked**
* **Reports** required by various stakeholders
* **Organisational structures** (e.g., escalation routes)

## **Example Use Cases**

| Use Case                          | Required Hierarchy               |
| --------------------------------- | -------------------------------- |
| City-level performance dashboards | City → Zone → Ward               |
| Revenue collection                | State → Division → Circle → Ward |
| Escalation workflow in complaints | City → Department Zones          |

***