Zones, Regions & Pincodes

The three building blocks AIR uses to describe "where" — a coarse sales Zone, a fine-grained administrative Region tree, and the postal Pincodes that sit under a region. Warehouses, customer addresses and carrier serviceability all point back to these records.

How the three fit together

A Zone is a broad grouping used for sales/administrative rollups — think of it as a label you attach to a set of Regions. A Region is the real geographic unit and is organised as a tree: every region (except the top-level country row) has a Parent Region, and the console tracks how deep in the tree a region sits via a computed Depth column. The conventional depth of the tree runs Country → State → District → Sub-District → Town/Village, one region_type per level. A Pincode is a postal code record that links back into that Region tree, and is where carrier serviceability and warehouse/customer addresses are ultimately anchored.

A pincode carries three links to Regions: a State, a District and a Taluka, chosen as a cascade — see the form below. That is the whole of a pincode's geography. The older single Region link, and the three India Post text boxes that sat beside the selects, were removed in August 2026; if you remember filling those in, you no longer need to.

When a customer address is created without an explicit region, it inherits the deepest of the three that is filled in — Taluka if set, otherwise District, otherwise State, otherwise nothing. Fill in as far down the cascade as you reliably can: that inherited region is what customer visibility is filtered on, so a pincode left at State level only is visible to state-wide staff but not to someone scoped to a single district.

Zones

Zones live under Geography → Zones in the sidebar. Any number of Regions can be tagged into a Zone via the Regions tab.

Zones nest. A Zone can sit under a parent Zone, so you can model a West Zone with Maharashtra and Gujarat sub-zones beneath it. Leave Parent Zone empty and the zone is top-level; set it and the zone becomes a sub-zone of whatever you choose. There is no depth limit. As with Regions, the system refuses to create a loop: you cannot make a zone its own parent, and you cannot move a zone underneath one of its own descendants — the save is rejected with an error rather than silently corrupting the tree.

Zone list

Filter: Active Status (yes/no/either) is the only filter on this list.

Create / edit a Zone

Select New zone on the list, or Edit on a row. The form is a single section, "Zone Details":

Regions tab

Open a Zone and switch to its Regions relation manager to see and manage which Regions are tagged into it.

Actions here: header Create (adds a brand-new region, pre-tagged to this zone), row Edit, and row Delete. Unlike the Zone delete you just read about, this Delete is guarded — it reuses the same protective check described in Deleting a Region below, even though you triggered it from inside a Zone's tab.

Regions Built

Regions live under Geography → Regions. This is the console's fullest geography editor: create, edit and delete, plus two relation managers for the region's children and its pincodes.

Region list

Filters:

Create / edit a Region

The form is organised into three sections. Only "Region Details" is expanded by default — the rest are collapsible and start collapsed.

Region Details

Government Codes (collapsible)

Assignments (collapsible)

Deleting a Region

Select Delete on a region row, or the header Delete action on a region's edit page. Before anything is removed, the console runs a protective check and will refuse to delete a region that is still in use:

This same guard is reused in two other places, so the rule is consistent everywhere you can delete a region: the Delete action inside a Region's own Children tab, and the Delete action inside a Zone's Regions tab.

Children tab

Open a Region and switch to Children to see every region one level directly beneath it.

Header Create adds a new child directly under this region (name, type and active toggle only — the parent is set automatically). Row Edit and Delete are available; Delete uses the same guard described above.

Pincodes tab

Open a Region and switch to Pincodes to see every pincode filed under it.

This tab lists the pincodes whose State is this region. It used to follow the old single Region link; with that link gone it follows the State link instead, which is what the old one meant in practice. A district or town/village region will therefore show an empty Pincodes tab even when pincodes point at it as their District or Taluka — use Geography → Pincodes and the District filter for those.

Header Create opens a short form (pincode, office name, active toggle) that files a new pincode straight under this region. Row Edit and Delete are plain — unlike the region-delete guard above, deleting a pincode here is not blocked by any check.

Pincodes Built

Pincodes also have their own full page at Geography → Pincodes — the same records you can reach from a Region's Pincodes tab, but listing every pincode in the system regardless of which region it sits under, with its own filters.

Pincode list

Filters: Active Status (yes/no/either), plus State and District — searchable selects over the real Region tree, matching the linked State/District described in the form below. The old Region (legacy) filter is gone, along with the link it filtered on.

Search (the box above the list) matches the pincode number and the office name only. It no longer searches place names — there is no place-name text on a pincode any more. To find every pincode in a district, use the District filter rather than typing the district's name.

Create / edit a Pincode

The form has four sections; "Pincode Details" and "System Links" are expanded, "Location" and "Contact" are collapsible.

Pincode Details

Location (collapsible)

Geography here is only the three linked selects, which point at real Region records. The State (India Post text), District (India Post text) and Taluka (India Post text) boxes that used to sit beside them were removed in August 2026 — the rest of the fields in this section are India Post's own postal-administration labels, which are reference text and not geography.

Contact (collapsible, starts collapsed)

System Links

Carrier Serviceability tab

Open a Pincode and switch to its relation manager to record which delivery carriers can serve this pincode.

Header Create opens a form: carrier_code (required, max 50), is_serviceable (toggle, defaults off), is_metro (toggle, defaults off), zone (text, max 5). Row Edit and Delete are plain, with no guard.

Bulk pincode import (CSV)

The import takes a CSV, matches each row to an existing pincode by its 6-digit code, and updates it or creates it. It runs in the background in batches, so a large file returns immediately with a job reference rather than making you wait.

Column headings must be the system's own field names, not India Post's. The recognised headings are pincode (required) plus office_name, office_type, delivery_status, division_name, postal_region_name, circle_name, head_office, sub_office, telephone, general_notes, is_active, the three place-name columns state_name, district_name, taluka, and the three link columns state_region_id, district_region_id, taluka_region_id. Anything else in the file is ignored.

The place-name columns are still read from the file even though a pincode no longer stores them — they are the input to the matching described below, and nothing else. An India Post export works unchanged; the names are used to find the Regions and are then discarded. The old region_id heading is no longer recognised.

What the import does with State, District and Taluka

Normally you put only the names in the file. The import reads the state_name, district_name and taluka text and tries to match each one to a real Region record, then sets the links for you. Matching ignores capitals and stray spaces, so NAGPUR, Nagpur and Nagpur  all land on the one Nagpur record. It also ignores a leading "The" in either direction — India Post writes THE DADRA AND NAGAR HAVELI AND DAMAN AND DIU where our record has no "The" (52 post offices used to fail on that alone), while The Nilgiris is a genuine district name, so a file saying Nilgiris matches it too. That is the whole point of the exercise: one row per real place, no near-duplicate spellings.

Two rules govern what happens when a name does not match:

• Nothing is invented. An unmatched name leaves that link empty and is reported to you. The import will never create a new Region to make a name fit — doing so would recreate the duplicate-spelling mess this is meant to clear up.
• A failure cascades downwards. If the state does not match, the district and taluka are not even attempted (and are reported too). This is deliberate: a misspelt state must never quietly park its districts underneath the wrong state.

Reviewing the "unresolved" report

Checking the import's progress also returns the list of names it could not match. Two things come back:

A non-zero count is not a broken import — the pincodes themselves were created or updated normally. It means those rows are missing their geography links, so they will not show up under the State or District filters and will not be counted in any report that goes by region. Work through the list: usually the fix is to create the missing District or Taluka Region (under the correct parent), then re-run the import so the names match on the second pass.

A last prerequisite worth knowing: state matching only works because all 28 states and 8 union territories are pre-loaded as Regions when the system is set up. Districts and talukas are not — they arrive from imports and from the old-system migration, which is why they are the levels that usually turn up in the unresolved list. On the full India Post file that split is measured: 99.47% of pincodes match a state (19,483 of 19,587; the handful that do not are rows where India Post wrote the state as literally NA), and none match a district, simply because no districts exist yet to match against. Expect a very long unresolved list on the first run — that is the districts, and it is the work list for creating them.

Where else these records are used

Regions and Pincodes are not self-contained — other modules point at them:

• A Warehouse can be linked to a Region and a Pincode directly on its own form, and separately to a whole set of Regions it serves via its Regions tab.
• Customer addresses reference both a Pincode and a Region.
• A user's geography scope — which part of the country they are allowed to work in — is expressed as a Region reference. Deleting a Region that still backs a scope is exactly the case the delete guard above exists to catch.

See also Warehouses & Carriers for how Regions attach to a Warehouse's serviceable area, and Schedulers for the background jobs that read warehouse/region data every day.