Resequence a route

Once a route exists, you'll often change it — add a late order, drop one, move a few stops around — and then want the sequence and timing to catch up with those changes. Two actions in the route drawer do that: Resequence re-solves the stop order, and Calculate Timing refreshes the arrival and departure estimates. Both live on the Routes tab and both work on a route that hasn't been dispatched yet. For the hands-on edits that come before them, see Edit a route.

Resequence

Resequence re-runs optimization on just this route's stops, looking for a better sequence than the one it currently has. It's the right move after you've added, removed, or moved stops by hand and would rather have Nash re-solve the ordering than work it out yourself. Where the original optimization worked across a whole set of orders, a resequence is scoped to the one route you're looking at. This action was previously labelled Reoptimize; it's the same action under a new name.

You'll find it in two places: as a button in the route drawer, and in the three-dot menu on the route's card in the map view.

Selecting Resequence opens a confirmation, Resequence this route?, before anything runs. It spells out the two things worth knowing up front: changes are saved automatically — the new stop order and arrival times are applied to the route as soon as the resequence finishes, with no separate step to accept them — and you'll get a before-and-after comparison to review once it's done. Choose Resequence to go ahead, or Cancel to leave the route as it is.

The resequence can take a moment. The route keeps its current stop order until the result is ready, and the route's other actions wait while it runs.

What a resequence changes, and what it doesn't

Resequence changes the order the stops are visited in, and the arrival and departure times that follow from it. It doesn't change who's carrying the route or which orders are on it.

That second point holds even when the route is over one of its limits. By default, a resequence keeps every stop you put on the route: rather than dropping a stop that doesn't fit the vehicle's capacity, the driver's shift, an order limit, a required vehicle capability, or a delivery window, it places the stop anyway and reports the limit it broke. If the optimizer can't place every stop even then, the route is left exactly as it was and you're told the resequence didn't go through — you never end up with a route that's quietly missing an order. In some organizations the resequence goes through instead: any stop the optimizer couldn't place is kept at the end of the route, just before its end point, and reported with the limit it broke. Availability varies by organization — reach out to Nash for access. A route with no orders on it can't be resequenced.

If a stop has sequencing set on its order — a Sequence Priority, for example — the resequence takes that into account. See Edit a route for how to set it.

The re-solve also isn't generic. It uses the route's own setup — the optimization strategy the route was built under and the vehicle settings from its shift or contract, as they're configured now — so things like traffic, service times, the vehicle's profile, driver breaks, and road restrictions carry through. Settings that only make sense across a whole fleet, such as balancing work between routes, don't apply to a single-route resequence. A route that can't be traced back to a strategy or contract is resequenced with standard defaults instead.

Review the result

When the resequence finishes, a Resequence result opens with the route before and after:

• A summary counts Stops moved and Timing updates.
• A table lists each changed stop with its Before and After position, arrival, and departure. Choose Show all stops to see the stops that didn't change as well.
• If the optimizer found nothing better, the result says No route changes — the stop order and timing are unchanged. That's a normal outcome, not an error.
• If any stop was kept despite breaking a limit, the result leads with Every stop kept and the number of constraint violations, followed by the list — late stops, capacity, order limit, shift end, or a missing vehicle capability.

Those violations stay marked on the route after you close the result. They show in the route drawer and on the route's map card, and in the drawer you can Acknowledge them to record that you've seen them.

To get back to the comparison later in the same session, choose View changes — it appears beside the route's actions in the drawer, and in the card's three-dot menu on the map, once a result exists for that route.

Resequence several routes at once

Note

Bulk route actions aren't available to every organization. Availability varies by organization — reach out to Nash for access.

Where bulk route actions are available, Resequence and Calculate Timing also appear in the bar that shows when you select routes in the Routes table, and in the three-dot menu on the focus chip when you have two or more routes focused on the map — see work with orders and routes on the map.

A bulk resequence asks you to confirm first, then works through each route independently: each route's stop order is recalculated and saved, and a route that can't be resequenced is left unchanged while the others still run. A bulk Calculate Timing runs right away, as it does for one route. Dispatched and archived routes in your selection are skipped. When the run finishes, a message tells you how many routes were updated; if any were left unchanged, choose Review to see which ones and why.

Calculate Timing

Calculate Timing computes arrival and departure estimates across every stop on the route, based on its current sequence. It doesn't move any stops. It runs as soon as you select it — there's no confirmation — and then opens a Timing result with the same before-and-after comparison a resequence gives you, showing which stops' times changed.

A resequence already saves fresh arrival times along with the new order, so Calculate Timing is mostly for the changes you make by hand. Reordering, adding, or removing stops doesn't always re-time the route on its own — whether an edit re-times the route automatically varies by organization. When a route's times have fallen behind its stops, the route drawer and the route's map card show Times are out of date, with a Recalculate button that does the same thing as Calculate Timing.

Think of it as the check step: reshape the route, then Calculate Timing to see the real arrival and departure picture before you commit to dispatching it.

Both lock after dispatch

Resequence and Calculate Timing are structural actions, so they lock the moment you dispatch a route — along with Split and Dispatch itself. A dispatched route is the record of what went out, and re-solving or re-timing it after the fact would mean that record no longer matched the work. Do your resequencing and timing checks while the route is still a draft. See Dispatch a route for what dispatch commits, and How routes work for the fuller editable-then-locked picture.

Availability

These actions depend on whether your organization has routes enabled, and Calculate Timing also depends on route timing being available to your organization. If you don't see the Routes tab or the Resequence and Calculate Timing actions, or Calculate Timing doesn't return a result, availability varies by org — reach out to Nash.