# 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 ](/complaints-management/complaints-resolution-v2.10/deploy/configure/boundary.md)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          |

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.digit.org/complaints-management/complaints-resolution-v2.10/design/architecture/boundary-hierarchy.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.