How workflows work

Note

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

A workflow is one idea repeated in a hundred shapes: watch for something to happen, then act on the job for you. The overview introduces that idea and names the three pieces every workflow is built from. This article goes underneath it — what actually decides which fields you can filter on, why the same action appears in one workflow and not another, where the "events" in "workflows and events" come from, and what happens between the moment a workflow is triggered and the moment its actions run. Read it once and the rest of the collection — building, running, monitoring, and the reference catalogs — stops feeling like separate features and starts reading as one system.

One thing to fix in place before the detail: Nash dispatches the job, and a provider or your own fleet carries it out. When a workflow cancels or reassigns a delivery, it's acting on the dispatch — the assignment Nash made — not performing or undoing the physical drive. Keep that framing for every action below that touches a delivery.

The model: trigger, logic, actions

Every workflow is a chain you build visually on a canvas under Orchestrate ▸ Workflows — no code, just nodes you connect left to right. The chain always has the same shape:

1. A trigger starts it. There is exactly one trigger per workflow, and it's the event the workflow waits for — a job created, a delivery running late, a proof-of-delivery photo uploaded.
2. Logic in the middle decides whether to keep going and which way to go. You have three kinds to reach for: a filter ("continue only if the job is over $200"), a yes/no split that sends the workflow down one of two paths, and a branch — the multi-way split that fans into several paths at once, one per case you define. Logic is optional; a workflow can go straight from trigger to action.
3. Actions are what Nash does once the logic passes: tag the job, set a dispatch strategy, send a message, flag it, cancel it, and more.

You can chain logic and actions freely — filter, then branch, then a different action on each branch — so a single workflow can react differently to a high-value job than to an ordinary one, or notify one team on the yes path and another on the no path. The canvas is where you compose that; this article is about the rules that govern what you're allowed to compose.

The trigger's context shapes everything after it

The single most useful thing to understand about the model is that the trigger doesn't just start the workflow — it sets the context the whole workflow runs in. Every trigger is about one kind of thing: an order, a delivery, a task, or a job. That context is not cosmetic. It decides two concrete things downstream:

• Which fields your logic can test. A delivery-context trigger gives your filters delivery attributes to compare against — status, timing, the driver's location. An order-context trigger gives them order attributes instead. You can only filter on what the context actually carries.
• Which actions are available. "Set dispatch strategy" and "Cancel order" make sense only when the workflow is holding an order, so they appear on order-context workflows. "Flag delivery" and "Cancel delivery" appear when the context is a delivery. Pick a trigger and the action list further down changes to match.

This is why two workflows that look structurally identical can offer different building blocks: they started from triggers with different contexts. When an action or a field you expected isn't in the list, the trigger's context is almost always the reason. The full breakdown of which fields and operators each context exposes lives in workflow triggers, conditions, and actions.

What can trigger a workflow

A workflow's trigger is an event — something Nash detects happening in your operation. The catalog of events you can trigger on is large, and it's not a separate list you have to learn: it's the same catalog that fires customer notifications. Every workflow trigger is backed by the same detection that sits behind a notification — a delivery crossing a status, an ETA slipping past its promised time, a delivery stuck too long in one status, a proof-of-delivery photo landing, an order needing attention. When that detection trips, a notification can announce it to your customer and a workflow can react to it with automation, off the very same signal.

Because the two share one catalog, this article doesn't re-list the events. They're enumerated once, with the fields each one exposes, in the notification events and variables reference. Read that list as your menu of workflow triggers too.

One trigger stands apart from that shared catalog and is worth naming on its own:

• Custom Event. A workflow can start when another workflow emits a custom event. This is the seam that lets workflows hand off to each other, covered in its own section below.

What a workflow can do

Once a trigger has fired and your logic has passed, the workflow runs its actions. The set is broad — this section is the shape of it, and the workflow actions reference is the full, scannable catalog with every label and where each one is available. At a high level, an action can:

• Tag or annotate the job — add one or more tags so you can find and sort it later.
• Steer dispatch and routing — set the order's dispatch strategy or its optimization strategy, so the workflow decides how Nash dispatches this job. See dispatch strategies for what those strategies are.
• Send a message — an email or SMS to a customer, or a message to your own team in Slack or Microsoft Teams.
• Flag or cancel — flag a delivery so it surfaces on your Deliveries page for someone to look at, or cancel the order or delivery outright. Cancel and reassign act on the dispatch, not on a driver mid-drive.
• Reach an outside system — call an external system with an HTTP request, to push the event somewhere you run yourself.
• Bring in AI — summarize an order's details into a value later steps can use, or hand the step to a configured agent.
• Emit a custom event — the action that powers the handoff described next.

A handful of actions are available for some organizations rather than everywhere — Send a Teams message, Run browser automation, and Run Custom Agent among them. If one of those isn't in your action list, it's gated for your organization rather than missing; reach out to Nash if you need it. And remember the context rule from earlier: even an action your organization has may be absent simply because the trigger's context doesn't support it.

Custom events: the "events" half

The collection is called "workflows and events," and this is the events half. A custom event is a signal one workflow emits and another workflow listens for — the way two workflows talk to each other without being wired together directly.

It works in two moves:

• Emit. One of a workflow's actions is Add custom event. When that workflow reaches the action, it emits a named event into Nash.
• Listen. Another workflow uses the Custom Event trigger and starts up whenever that named event fires.

That's the whole bridge: one workflow detects a situation and emits an event; any number of other workflows react to it. It lets you keep each workflow small and single-purpose — one notices, another responds — and it lets you fan a single detection out to several reactions. The same custom event can also feed a customer notification, so an internal automation and a customer-facing message can hang off one shared signal; the notification side of that bridge is described in how tracking and notifications work.

Before workflows can emit and listen, the custom event has to exist. Custom events are defined in their own place in the portal, and defining one needs organization-management permission — so it's typically an admin who registers the vocabulary your workflows then use. The step-by-step for defining, emitting, and listening is in use custom events.

How a workflow runs

Building a workflow and having it run are two different things, and the gap between them is worth understanding.

Only an active, current workflow fires. A workflow you're still editing sits inactive and reacts to nothing. When you enable it, Nash watches for its trigger from then on. And every save creates a new version behind the scenes, but only the latest one is live — so the workflow that fires is always the most recent version you activated, never a stale copy. You don't manage those versions by hand; you edit, save, and enable, and Nash keeps the live one straight.

You can try a workflow before you trust it. From the editor you can test a workflow against a real job by its ID. A test can run as a dry run — it walks the logic and shows you what would happen without firing any real actions, so you can confirm the filters and branches behave — or as a live test that actually sends, clearly marked as a test so it's never mistaken for the real thing. Running a workflow for real is deliberately separate and warns you that it's a production run: it executes end to end and fires every action it reaches. Running one on demand against jobs you choose is covered in run a workflow manually.

Every run is recorded. Each time a workflow fires — on its own or because you ran it — it leaves an entry in the workflow's execution history, with a status you can read at a glance: Running while it's in progress, Paused if it's waiting, Passed when it completed, Filtered when the logic stopped it short (the trigger fired but a condition said "don't continue"), and Ready when it's queued to go. That "Filtered" status is the one operators misread most often: a filtered run is not a failure — it's the workflow correctly deciding this particular job didn't meet the conditions, so nothing downstream should happen. Reading that history, and telling a healthy filter from a genuine problem, is covered in monitor workflow runs.

Put the three together and the lifecycle is simple to hold in your head: you build a workflow from a trigger, some logic, and some actions; you test it safely, then enable it; from that point Nash watches for the trigger, runs the live version when it fires, and writes down what happened so you can check it later.