How exceptions work

Last updated: October 29, 2026

Note

This is a beta feature. Reach out to Nash if you'd like early access.

An exception is a flag on a live route. It records that something on the route needs a person's attention, what kind of problem it is, how urgent it is, where your team is with it, and who owns it. Everything else in this article — where exceptions come from, how severity is set, why assignment covers the whole route, when an exception closes without anyone touching it — follows from that one fact: an exception belongs to a route, not to an order or a stop.

Exception handling is an add-on within Execute. Exceptions appear only when exception handling is on for your organization; if it isn't, reach out to Nash.

How it works

Every exception carries four things:

Type — what happened: Late departure, Vehicle breakdown, Customer not home, one of your organization's own types, and so on. The type decides the icon and label you see in the queue.
Severity — how urgent it is, from Critical · P0 down to Low · P3. Severity sorts the queue and drives the page header.
Status — Needs Triage, Acknowledged, or Resolved. The first two are open; resolved exceptions move out of the queue.
Assignee — the teammate who owns it, or Unassigned.

Because an exception attaches to a route, one route can hold several at once: a late departure at the start of the run, then a refuel request halfway through. The Execute routes table shows one of them in the Exception column — the route's leading open exception, which is the most severe one, with the oldest winning a tie — plus a count of the rest. The route panel's Issues tab lists all of them. A route with no open exception shows an Add exception button in that column instead.

Some exceptions also record details from when they were raised — the planned start and delay on a late departure, the breakdown location and the stops it affects, the attempt number on a customer-not-home — and a Customer impact count where Nash can work one out. You see those details when you open the exception.

Where exceptions come from

Exceptions reach a route from four places. Whatever the source, they land in the same queue and work the same way afterward.

Raised by hand in Execute

Anyone working in Execute can add an exception when they learn about a problem before the system does — a driver calls in, a store complains. Select Add exception in a route's Exception cell, or Flag route on the route's Issues tab, pick a type, fill in what you know, and choose a severity or leave it on Auto. You can raise any of these built-in types by hand: Late departure, Vehicle breakdown, Catchment violation, Customer not home, Ad-hoc break, Vehicle overweight, Vehicle oversize, Refuel request, and Break compliance violation (only on a route with a scheduled break). If your organization has its own exception types, they appear first, under Your exception types. See Add an exception to a route.

One more exception starts from a person's action: an Order cancellation request. Selecting Request Cancellation on an order on a live route doesn't cancel the order straight away. It raises an exception on the route, so the change can be reviewed and the rest of the route re-planned around it. See Request an order cancellation on a live route.

Reported from the driver app

Drivers report problems from a stop's menu in the driver app, and each report becomes an exception on their route:

Report Breakdown raises a Vehicle breakdown, with the driver's location and the stops still to come.
Report Overweight and Report Oversize raise Vehicle overweight and Vehicle oversize.
Request Refuel raises a Refuel request.
Failing a drop-off because the customer wasn't home raises a Customer not home, one per delivery at that stop, with the attempt number.

What drivers see on their side is covered in Handle exceptions.

Raised from route events

Nash watches two route events and raises an exception when they cross a line:

Late departure — when a driver starts a route 15 minutes or more after its planned start. The exception records the delay and the drop-offs at risk of missing their windows because of it.
Break compliance violation — when the driver's location shows the vehicle moving during a scheduled break on the driver's shift.

Raised by your workflows

Workflows can manage exceptions with four actions: Create route flag, Update route flag, Resolve route flag, and Assign route flags. A workflow that creates one can classify it with one of your organization's exception types; without a type, it shows as Workflow. The workflow decides what happens when the same issue comes up again — Reopen the same flag or Open a new flag — and whether it may change an exception someone is already working, under When someone is already working the flag. The default, Leave it alone, never overwrites an exception that a person has acknowledged, been assigned, or raised.

The workflow actions are available for some organizations.

When the same problem repeats

Automatic sources don't stack duplicates. While an exception still reads Needs Triage, a repeat of the same event on the same route — a second tap on Report Breakdown, another late-departure check — updates that exception instead of opening a new one. Once someone has acknowledged it, a fresh occurrence opens its own exception. Built-in types you add by hand follow the same rule — adding a Vehicle breakdown to a route that already has one waiting for triage updates that one. Exceptions of your organization's own types are always new.

How severity is set

Severity comes from one of three places, in this order:

Someone picks it. Choosing P0–P3 in the Add exception dialog, or a severity in a workflow action, sets it outright.
The type's rule. On Auto — the default in the dialog, and what every driver report and route event uses — Nash rates a built-in exception from its details. The rules are in the table below.
The type's default severity. Your organization's own types carry a Default severity, and Auto uses it. A workflow exception with no type and no severity is P2.

Built-in type	Auto severity
Late departure	P0 at 30 minutes late or more, or when 3 or more stops are at risk; P1 at 15–29 minutes; P2 under 15 minutes
Vehicle breakdown	P0 when a remaining stop's delivery window closes within 30 minutes; otherwise P1
Customer not home	P3 on the first attempt, P2 on the second, P1 on the third or later
Ad-hoc break	P1 when the break pushes a remaining stop past its window; otherwise P2
Vehicle overweight, Vehicle oversize	P1
Catchment violation, Refuel request, Break compliance violation, Order cancellation request	P2

When you raise a built-in type by hand on Auto, the rule reads what you entered — the delay and at-risk stops for a late departure, the attempt number for a customer-not-home — so a hand-raised exception gets the same rating an automatic one would.

Severity can change after the fact. Anyone who can edit exceptions can set a new severity in the exception's details, and a repeat of the same event can re-rate an exception that's still waiting for triage.

The status lifecycle

An exception moves through three statuses:

Needs Triage — new, and nobody has looked at it yet. Every exception starts here.
Acknowledged — someone has seen it and is on it. The quickest way there is the Acknowledge button on the exception's row, or Acknowledge all on the route's Needs Triage group.
Resolved — done. A resolved exception leaves the queue and moves to the route's Resolved section.

You can move an exception back from Acknowledged to Needs Triage if it needs a fresh look. Resolving is final in the portal: a resolved exception's details are read-only.

When an exception turns out to be a false alarm, set its status to Nullify · false alarm instead of Resolved. It closes the same way, with the note Nullified from triage, so anyone reading the history later can tell a false alarm from a fixed problem.

If your organization has its own exception types, you can also change an open exception's Exception type. Changing the type closes the original exception — its record reads Exception type changed — and opens a new one of the new type with the same severity, status, notes, and assignee.

All of these changes happen in the exception's details; see Triage and resolve exceptions. If the fields there are read-only, your role doesn't include permission to change exceptions — ask an admin in your organization.

Assignment covers the whole route

An exception's assignee isn't set one exception at a time. Assigning anyone to an exception assigns them to every open exception on that route, and clearing the assignee clears it for all of them. The details panel says so under the field: changing the assignee applies to all open exceptions on the route. One route, one owner.

The same rule carries forward. When a new exception lands on a route whose open exceptions already have an assignee, it joins that assignment automatically, so the person working the route sees the new problem too. You can assign from the Assignee column, from an exception's details, or for several routes at once by selecting rows in the table and choosing Assign to or Clear assignee. See Assign exceptions.

What the assignee hears

The assignee gets an in-app notification in the portal when:

they're assigned a route that has open exceptions,
a new exception is added to a route they're assigned to,
an exception on their route is raised to a more severe level, or
an exception they acknowledged is moved back to Needs Triage.

Nobody is notified about their own change: assigning yourself, or raising an exception on your own route, sends nothing.

How exceptions close

An exception closes in one of these ways:

A person resolves it — or nullifies it as a false alarm — from its details. The record shows who resolved it.
A workflow resolves it with the Resolve route flag action.
Applying a re-optimized plan closes an Order cancellation request; its record reads Re-optimized.
Changing its type closes the original as Exception type changed.
The route ends while nobody has taken the exception.

When the route ends

Open exceptions don't pile up on finished routes. When a route is completed, canceled, archived, or deleted, Nash closes every open exception on it that nobody has taken. Each one closes without a resolver, and its record reads Closed when the route ended, with a note naming how the route ended.

Some exceptions stay open after the route ends, because someone still needs to follow up:

Exceptions a person has taken — anything someone acknowledged, or any exception with an assignee.
Exceptions a person raised — anything added by hand in Execute, including order cancellation requests.
Every exception on a failed route. A failed route needs follow-up, so nothing on it closes automatically.
Exceptions raised in reaction to the route ending — for example, a workflow that opens a follow-up when a route completes. Only exceptions that were already open at the moment the route ended are closed.

These stay in the queue until someone resolves them. If you'd rather an exception close on its own when the route finishes, leave it unassigned and unacknowledged.

Where the history lives

Resolved exceptions stay with their route. On the route panel's Issues tab, a collapsed Resolved section sits under the open ones; expand it to see every closed exception on the route. Open one to see how it closed: who resolved it, the outcome — Closed when the route ended, Exception type changed, Re-optimized — when it was last updated, and any resolution notes.

While an exception is open, its progress also shows on the route panel's Activity tab, alongside the route's own events: when it was raised, each change made to it, and who made the change. Once it's resolved, its record is in the Resolved section.

Your organization's exception types

Built-in types cover common problems on the road. Your operation has its own — a late store dispense, a missing seal, a gate code that didn't work. Your organization can keep its own catalog of exception types under Settings ▸ Preferences ▸ Exceptions, by selecting Manage exception types.

Each type has a Name, a Type key that workflows use to raise it and that can't be changed later, a Description telling your team when to use it, a Default severity, and a Color. Your types appear first in the Add exception dialog, in the Trigger Type filter, and in the Exception type picker when you retype an exception. Archiving a type hides it from every picker; exceptions that already used it keep it in their history. A type that a workflow still uses can't be archived until the workflow is changed.

The catalog also lists Nash's built-in types, which are read-only, and a fallback type, Unclassified. If a workflow raises an exception with a type that no longer exists — because it was archived after the workflow was saved, say — the exception lands as Unclassified instead of being dropped, and its details show the original type key so you can trace it.

Managing the catalog takes permission to manage organization settings, such as the Owner or Admin role. See Manage exception types.

What affects this

Whether exception handling is on. Without it, Execute shows routes with no Exception or Assignee column and no Issues tab.
Your role. Seeing exceptions comes with Execute access. Changing them — status, severity, type, assignee — needs permission to change exceptions. Managing the exception-type catalog needs permission to manage organization settings.
Your workflows. A workflow can raise, update, assign, and resolve exceptions, and its settings decide whether it reopens an old exception or leaves a person's work alone.
Who has taken an exception. Acknowledging or assigning an exception keeps it open after the route ends.

Nash dispatches routes to providers and fleets; they carry out the deliveries. An exception is how a problem on one of those routes reaches your team, and the record of what your team did about it.