What workflows are and when to use one
Last updated: August 4, 2026
A workflow watches for something to happen in Nash and then acts on it automatically — "when this happens, do that." Instead of your team checking every job by hand, Nash applies your rules the moment they apply.
When to reach for a workflow
Workflows are worth setting up whenever you find yourself repeating the same decision. A few common examples:
Route high-value jobs differently. When a job comes in above a certain value, automatically apply a more reliable dispatch strategy.
Catch problems early. When a job is flagged or running late, notify the right channel so someone can step in.
Keep things organized. Automatically tag or sort jobs by destination, service level, or any attribute you track.
A workflow can act on a single job or on many, and it works the same whether those jobs go to your own fleet, to a delivery provider, or to both.
How a workflow is built
Every workflow is three things:
A trigger — what starts it (for example, a new job is created).
Conditions — optional checks that decide whether to continue, and which path to take (for example, "only if the job is over $200").
Actions — what Nash does (apply a strategy, send a notification, tag the job, and more).
You build all of this visually in the portal — no code required. See Build a workflow in the portal to create your first one.
Try before you turn it on
You don't have to activate a workflow to see what it does. You can run one by hand against jobs you choose — handy for applying a workflow to older jobs, or for checking a change before it goes live. See Run a workflow manually.
Building with the API?
This article covers the portal experience. If you're automating workflows programmatically — the full trigger, condition, and action model, plus the /v1/workflows endpoints — see the developer reference: Workflows on docs.usenash.com →.