What workflows are and when to use one

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:

1. A trigger — what starts it (for example, a new job is created).
2. Conditions — optional checks that decide whether to continue, and which path to take (for example, "only if the job is over $200").
3. 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 →.