Workflows at a glance

Note

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

A workflow watches for something to happen in Nash and acts on the job for you — "when this happens, do that." Instead of your team watching for a condition by hand and reacting to it every time, Nash applies your rule the moment it's true.

Every workflow is built from the same three pieces:

• A trigger — the event that starts it: a job created, a delivery running late, a job flagged. The trigger also sets the context — order, delivery, task, or job — which shapes which fields you can filter on and which actions are available further down the workflow. Most triggers are the same events that can fire a customer notification.
• Logic — the checks in between that decide whether to continue and which path to take: a filter ("only if the job is over $200"), a yes/no branch, or a multi-way split.
• Actions — what Nash does once the logic passes: tag the job, apply a dispatch or optimization strategy, send a message, flag it for review, cancel it, call a webhook, and more.

You build all of this visually in the portal under Orchestrate ▸ Workflows — no code required, a canvas where you connect a trigger to logic to actions.

When to reach for a workflow

Workflows are worth setting up whenever you find yourself repeating the same reaction by hand — routing high-value jobs to a more reliable dispatch strategy, alerting your team the moment a job is flagged or running late, tagging and sorting jobs by destination. A workflow can act on a single job or on many, and it works the same whether those jobs go to your own fleet, a delivery provider, or both — Nash dispatches the job; the provider or your own fleet carries it out, so a workflow's reassign or cancel action is acting on the dispatch, not the delivery itself.

The two halves: workflows and custom events

"Workflows and events" is two connected capabilities. Workflows are the trigger-logic-action automations above. Custom events are how one workflow hands off to another: a workflow emits a custom event as one of its actions, and any other workflow can listen for that event with a trigger of its own — one workflow detects, another reacts, without wiring them together directly. A custom event can also feed a customer notification, so an internal automation and a customer-facing message can share the same trigger.

Availability varies by organization — reach out to Nash if you don't see Workflows in your portal.

What you can do

• How workflows work — the model in more depth: trigger context, logic, the action catalog, and the custom-event bridge.
• Build a workflow in the portal — create a trigger, add logic, and choose actions.
• Run a workflow manually — run one on demand against jobs you choose.
• Monitor workflow runs — find a workflow's execution history.
• Use custom events — define, emit, and listen for a custom event.
• Workflow triggers, conditions, and actions — the full catalog you build a workflow out of.
• Workflow actions reference — every action, what it does, and where it's available.
• Route high-value jobs to a better strategy, Alert your team about late or flagged jobs, and Auto-tag jobs by destination — ready-made patterns to build from.

Related

A workflow's "Set dispatch strategy" action reaches into the same strategies you manage directly — see Dispatch strategies at a glance for how those are built. And because a custom event can trigger a customer message, workflows and customer notifications share a bridge — see How tracking and notifications work for the other side of that connection.