Boundary Hierarchy

Boundary Hierarchy Design – CCRS Context

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 to understand how to create boundaries in DIGIT

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

Default Boundary Setup in CCRS

Each tenant can define a boundary hierarchy within itself. For example, the default setup in CCRS 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

---