How locations work

A location is a store or site Nash keeps on file — a physical place an order is picked up from or dropped off at. That's the whole object in one line, but almost everything useful about locations hangs off two facts under it: a location is a saved record you point at, not an address you copy onto an order; and it comes in two kinds that carry very different amounts of detail. This article is about those two facts — what a location actually is, how the pickup and dropoff kinds differ, and how a saved place gets read at dispatch and routing time without ever moving an order on its own.

One boundary runs through all of it, worth stating up front: a location is geography you own and edit; it never dispatches or routes anything by itself. It sits in your address book until an order names it. Naming it is what puts it to work — and even then, Nash dispatches the order while a provider or your own fleet actually drives it. A location describes where; it doesn't perform the delivery.

How it works

Start with what "saved record you point at" really means. When you attach a location to an order, the order doesn't copy the address in — it references the saved location by its identity. Two consequences follow, and both matter in practice:

• You pick, you don't retype. Every order that leaves a given store reuses the same saved record, so the address, contact, hours, and instructions are entered once and reused everywhere. There's no chance of three orders to the same store carrying three slightly different addresses.
• The order tracks the record. Because the order points at the location rather than snapshotting it, the display label follows the record. A pickup location shows as Name (externalId) — its name next to your own store code — so a store you already call "Store 412" shows up as such wherever it's referenced.

That external ID is the pickup side's own handle for a location: your store code, the identifier you already use in your other systems. Saving it on the location is what lets you find and recognize a store by the code your business runs on, rather than by an address you'd have to remember.

The two kinds

A location comes in two kinds, and the difference isn't cosmetic — it's how much the record carries and what job it can do for an order.

	Pickup location	Dropoff location
What it is	A store or depot you dispatch from — the rich record	A recurring delivery address — the light record
Identity	Name plus an external ID (your store code), shown as "Name (externalId)"	Name and address
Address	Required, geocoded to a point, with its own timezone	Required; other address detail optional
Contact	A store contact	Optional name, phone, email
Instructions	Pickup instructions	Optional delivery instructions
Operational detail	Operating hours, pickup windows, prep and service time, blackout dates, picker capacity	—
Network detail	Routing settings, provider allocation, coverage, zone associations	—
Roles it can play	Pickup, and optionally dropoff too	Destination only

The thing to hold onto is that a single saved place can play both roles. The kind isn't a wall between two databases of stores versus addresses — it's what the point does for a given order. A store you pick up from can also be a place you deliver to; the pickup record simply carries far more, because a store is where a lot of an order's downstream behavior is really configured.

The pickup form grows with your setup

Because a pickup location carries so much, you create one through a stepped form rather than a single screen: pickup details → routing → zone details → integration → provider allocation → store inventory → coverage. The first steps — the address, contact, hours, and service time every store has — always appear. The later steps appear only when the matching capability applies to your organization: a routing step, the zones the store serves, a connected online ordering platform's settings, per-provider allocation, the products stocked there, and the coverage area.

So two operators at two organizations can see different forms for the same object, and neither is broken. If you see fewer steps than a colleague, the extra steps are conditional on your setup, not missing. Which steps appear, and every field on each, is laid out in the pickup location settings reference; the walkthrough for saving, importing, and exporting locations is in set up your pickup and dropoff locations.

Locations are available to every organization — there's nothing to enable to start saving them. The one gated piece around locations is who can work them:

Note

A Location Operations user is a built-in role that scopes a user to specific stores, so a store manager sees and acts on only their own locations rather than the whole network. It doesn't change what a location is or how it works — only who a given user can see. Availability varies by organization; reach out to Nash for access, and see set up a Location Operations user.

How locations relate to zones

Locations and zones both live on the same map, but they're different shapes doing different jobs: a location is a single point, and a zone is a deliver-here area. They're distinct objects — this page is about the point, and the zones overview is about the area — but a pickup location is where two of the connections between them are actually made.

• Zone details. A pickup location's form has a Zone details step: the zones this store serves. Associating a store with a zone is what ties the store to the coverage area it belongs to.
• Blocked Zones. The same form has a Blocked Zones section — zones a store is explicitly excluded from, the inverse of the association above.

From the zone's side, the relationship reads the other way: a zone lists the locations it covers. Same pair of objects, looked at from two directions. The mechanics of what a zone does with those associations — matching an order's dropoff, and binding an optimization strategy — belong to the zones overview and how zones work; this page stops at the location's edge of the relationship.

From saved to in use

The most useful way to hold a location is by state: what it is when you save it, and what puts it to work. A location has the simplest lifecycle of any geography object — there's no activation step to remember.

The moment you save it	What puts it in use	If nothing names it
A usable point in your address book, with everything it carries	Naming it as an order's pickup or dropoff	It just sits there — harmless, costs nothing

That simplicity is the point. A location doesn't need to be bound to a strategy or matched to anything the way a zone or a route restriction does; it's ready the instant it's saved, and it does nothing until an order picks it up. Saving is not the same as it being used — but the gap is small, because using a location is just selecting it on an order.

The one edge worth knowing is removal:

Important

Removing a location happens immediately, with no confirmation step and no undo. Be certain of the row before you delete it. A location fed by a connected online ordering platform may reappear on the next sync, but a hand-entered one has to be recreated from scratch — there's no restore.

What affects this

A location's own record is mostly self-contained, but a couple of things outside it change how a saved location behaves or where its details come from. Neither is a field you set on the location page directly.

Input	Where it's set	Effect on a location
A connected online ordering platform	The pickup form's integration step — see online ordering platforms	Can create and update pickup locations from an outside system, so a store's details may be set by the integration rather than by hand — and a deleted one may reappear on the next sync
Zones	Configure ▸ Network ▸ Zones — see zones overview	The zones a pickup location can be associated with or blocked from; the association is made on the location's Zone details step, but the zones themselves are defined on the Zones page
Location Operations role	Reach out to Nash	Scopes which locations a given user can see and work — a filter on access, not on the location record itself
Order attributes	The order itself	An order names a pickup and a dropoff location; whether a store's hours, prep time, or coverage come into play depends on the order that references it

The through-line is the same one the whole object sits inside: a location supplies the where, and the surfaces that dispatch orders and plan routes read it. Nash dispatches the order; the optimizer plans the route between the points you've saved; and a provider or your own fleet drives it. Saving a store or an address describes the ground an order runs on — it never, on its own, moves the order across it.

For the shorter tour of locations and where to find them, see the locations overview.