How zones work

A zone is a named geographic area you define once and reuse. That's the whole object in a sentence — but the sentence hides the thing that actually trips people up, which is that a zone, by itself, does nothing. It doesn't route an order, doesn't pick a carrier, doesn't open a delivery window. It's a description of where, drawn once and left sitting there, waiting for something else to read it. Everything useful a zone does, it does because a fleet, a delivery window, or an optimization strategy points at it and asks "is this order in that area?" This article is about that split: what a zone is on its own, and the three different jobs other systems put it to.

Before the detail, the boundary that runs through all of it: a zone defines geography you own and edit; it never moves an order by itself. It's read at dispatch and routing time. Nash dispatches the order, the optimizer plans the route inside the geography you've defined, and a provider or your own fleet actually drives it. Nothing on the Zones page performs a delivery or steers a vehicle — it describes the ground the delivery runs on.

How it works

A zone is an area paired with the store locations it applies to. You build the area one of two ways, and a single zone can combine both:

• By listing places — countries, states, cities, ZIP or postal codes, or city-and-ZIP pairs, typed in as entries.
• By drawing a polygon — a shape you trace on the map for coverage that doesn't follow a named administrative boundary.

A zone saves more than just its shape. Each one carries a name, an optional external ID, its coverage area (any mix of the categories above), the store locations it covers — each association optionally bounded by a date range — an attached optimization strategy, free-form metadata, tags, and an active/inactive flag. The full set of coverage categories and how polygon drawing works is in the zone coverage reference; the list, create, edit, and import/export flow is in manage zones.

The Zones screen organizes all of this across four tabs — Zones, Coverage, Restrictions, and Audit Log. From it you create and edit zones, draw coverage on the map, import and export via CSV, filter and sort, bulk-enable or disable delivery windows across zones, and review an audit log of changes.

Note

Zones don't carry an operator-facing lifecycle the way a delivery does. A zone is either active or inactive, and beyond that it's just a saved description of coverage. There's no state to move it through — the object is the geography, and its effect lives entirely in what reads it.

But drawing the shape is only half the story, and honestly the less interesting half. The reason a zone matters is what happens after you save it — and that depends entirely on which downstream system reads it.

The three jobs a zone gets put to

A zone is a single object, but it's referenced by three different systems, each of which uses the same geography to answer a different question. This is the crux of how zones work: the zone itself never decides anything, it's referenced by the thing that does.

1. Fleet geo-eligibility — deciding who can take an order

The first and most consequential job a zone does is shape which fleet is allowed to carry an order. An internal fleet picks a set of pickup zones and a set of dropoff zones as its service footprint — the geography it's willing to work. When an order comes in, that footprint is what decides whether the fleet is even in the running: an order whose pickup and dropoff fall inside a fleet's zones is one that fleet can take; one that falls outside them isn't.

That's how a zone changes who delivers. You don't set eligibility on the zone — you draw the zone here, and the fleet setup over in Fleet references it as part of its footprint. Redraw the zone's coverage and you've changed, in one move, the geography of every fleet that points at it. The zone is the shared definition; the fleet is what reads it to gate itself in or out.

2. Delivery windows — deciding when you deliver

The second job is scheduling. Delivery windows are scoped per zone — the promised delivery times you offer are defined against the zone an order's destination falls into, so different areas can carry different windows. A denser urban zone might offer tighter, more frequent windows than a rural one; the zone is what lets you express that difference instead of applying one blanket schedule everywhere.

This is also why the Zones screen lets you bulk-enable or disable delivery windows across zones: because the window lives against the zone, turning windows on or off is a zone-level action. The zone supplies the where; the delivery-window configuration supplies the when for that where.

3. Route optimization — deciding how a route is planned

The third job is routing. A zone can carry an attached optimization strategy, so that routing behaves differently inside that area than it does elsewhere. That binding is what turns a zone from a passive description of coverage into something that actually changes how a multi-stop route gets planned within it — different priorities, different constraints, inside that ground.

The binding is set up on the strategy side, not on the zone, and until a strategy is attached the zone changes nothing about routing. See optimization strategies for where that attachment happens and how optimization works for how the optimizer weighs it.

Same zone, three jobs. The framing that keeps this straight: the zone defines where; fleets, delivery windows, and strategies reference the zone to decide who, when, and how. None of those three decisions lives on the zone itself — the zone is the shared input they all read.

Address-to-zone resolution happens behind the scenes

There's one piece of this that isn't a portal setting at all, and it's worth naming so you don't go looking for it. Working out which zone a given order falls into — matching a delivery's address against every zone's coverage — happens server-side, automatically, whenever an order needs it. You don't run a match, and there's no "resolve" button. The portal is configuration only: you draw the coverage and attach it to locations, and the resolution that reads a real address against that coverage runs on its own downstream.

That division is why the shape you draw matters so much. The only lever you have over how an order gets matched is the coverage itself — get the polygon or the ZIP list right and resolution does the rest. A couple of consequences follow from that:

• Coverage areas can overlap. A single address can fall inside more than one zone at once. That's allowed — just know it's possible when you're reasoning about which zone's behavior an order picks up.
• An order can land outside every zone. An unmatched order isn't an error; it simply isn't "in a zone," so any zone-scoped behavior — a fleet's footprint, a per-zone delivery window, a zone-bound strategy — doesn't apply to it. If you expected zone behavior and didn't get it, check whether the address actually falls inside the coverage you drew before assuming something's broken.

The store-to-zone date range

One connection is easy to miss because it lives on the store, not the zone. When you attach a zone to a store location, that association can carry an optional date range, and that range is the one active window Nash enforces around zones: the store counts as part of the zone only between those dates. It's how you stage a zone ahead of time or wind one down on a schedule without redrawing it. You set it on the location's Zones step — see the pickup location settings reference.

Route restrictions live here too — but they're a different object

The Zones surface also owns route restrictions, and because they share this object it's worth stating plainly that a route restriction is not a zone. They're grouped together because both are areas you draw on a map for your network — but they do opposite jobs:

• A zone is a deliver-here area. Downstream systems read it to decide who, when, and how, as described above.
• A route restriction is an avoid-here area. It doesn't change what you deliver — it tells the multi-stop route optimizer which places a route must not enter.

And a route restriction reaches its effect a different way. A zone is read by fleets, windows, and strategies as soon as they point at it; a route restriction does nothing until you explicitly attach it to an optimization strategy or pick it in the Optimize flow for a single run. Drawing the restriction just adds it to your library of avoid-areas; the attachment is what makes the optimizer honor it. The step-by-step is in create route restrictions; where the attachment happens is optimization strategies and optimize orders.

Important

Don't confuse route restrictions with the Restrictions tab on the Zones screen. Route restrictions are the avoid-areas described here, distinct from zones and applied through optimization. If your organization has a separate zone-level restrictions feature, that's a different, narrowly scoped surface — not covered here.

What you can and can't change

The boundary is the same one running through every section above, so it's worth stating once, plainly.

You own the geography. Drawing a zone, listing its coverage, attaching it to locations, setting its date-bounded store associations, tagging it, and marking it active or inactive — that's all yours to edit in the portal. Core zones are available to every organization that has the surface; there's nothing to enable per zone.

You don't own the decisions that read the geography. A fleet's footprint is configured over in Fleet; a per-zone delivery window is configured against the window; a zone-bound optimization strategy is set up on the strategy side. The zone is the shared input all three reference — you change where by editing the zone, but who, when, and how are decided by the systems that read it, each on its own surface.

Note

Zones availability varies by organization — reach out to Nash for access. A zone's name is optional, but it's also the primary column you scan and search by, so a zone saved without one is genuinely hard to find later — name every zone.

What affects this

A zone is an input, but a handful of other objects decide what that input actually does once it's saved. None of them live on the Zones page; each is set elsewhere and felt here.

Object	Where it's set	What it does with a zone
An internal fleet's footprint	Configure ▸ Fleet	Reads a fleet's chosen pickup and dropoff zones to gate which orders that fleet is eligible to carry — the "who"
Delivery windows	Scoped per zone	The promised delivery times you offer are defined against a zone, so different areas carry different windows — the "when"
Optimization strategy	Orchestrate ▸ Optimization Strategies — see optimization strategies	A strategy bound to a zone changes how routes are planned inside it — the "how"
Store-to-zone association	Configure ▸ Network ▸ Locations, pickup form — see pickup location settings reference	Connects a store to a zone over an optional date range — the one active window Nash enforces around zones
Address-to-zone resolution	Server-side, automatic	Matches an order's address against zone coverage to decide which zone(s) it falls in; the portal is configuration only
Locations	Configure ▸ Network ▸ Locations — see locations overview	Supply the points a zone is attached to; a zone with no locations behind it has nothing to apply to

The through-line, in both directions: the zone supplies the geography, and the objects above decide what it counts for. Fleets read it to gate themselves, delivery windows read it to schedule, strategies read it to route.

And the boundary the whole object sits inside, one more time: Nash dispatches the order, the optimizer plans the route within the geography you've defined, and a provider or your own fleet drives it. Drawing a zone shapes the plan — which fleet is eligible, what window applies, how a route is built — it's never Nash delivering to a neighborhood itself. You define the ground; dispatch and routing decide what happens on it.

For the shorter tour of the Zones surface and where to find it, see the zones overview.