Use custom events

Last updated: August 31, 2026

A custom event is a named signal you create so one workflow can hand off to another. One workflow emits the event when it runs; another workflow starts up when that event fires. It's the "events" half of Workflows and events, and it lets you keep each workflow small and single-purpose — one notices a situation, another responds to it.

Note

Custom events are part of Workflows, a beta feature. Reach out to Nash if you'd like early access.

Using a custom event takes three moves: define the event, emit it from one workflow, and listen for it in another. For the model behind all of this, see how workflows work.

Define the event

Custom events are managed under Orchestrate ▸ Custom Events. An event is just a named signal — you create it once, give it a name, and then any workflow in your organization can emit it or listen for it.

Note

Defining custom events requires organization-management access. If you have it, you can create and manage events here yourself. If you don't, ask a Nash admin or your organization's owner to define the event for you — once it exists, anyone building a workflow can use it.

Emit the event from a workflow

To have a workflow raise the event when it runs, add the Add custom event action to that workflow. Build the workflow the usual way — a trigger, any conditions, then actions — and include Add custom event among the actions, choosing the event you defined. See build a workflow in the portal for the full walkthrough.

When that workflow reaches the action, it emits the named event. A common pattern is to place Add custom event at the end of a workflow, so the event means "this workflow just finished its job" — a clean signal for another workflow to pick up.

Listen for the event in another workflow

In the workflow you want to run in response, use the Custom Event trigger. Instead of firing on a delivery or order event, this workflow starts up whenever the named event is emitted. Pick Custom Event as the trigger, choose the event to listen for, then add the conditions and actions that workflow should run.

That's the whole bridge: the first workflow emits, the second one listens. The two are never wired together directly — they only share the event's name — so you can change either side independently.

Why use custom events

  • Chain one workflow to another. When a workflow finishes, have it emit an event that kicks off the next workflow — a hand-off you'd otherwise have to cram into a single, sprawling workflow.
  • Fan one signal out to many reactions. Several workflows can listen for the same event, so a single detection can drive multiple responses at once.
  • Bridge to a customer notification. 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 covered in how tracking and notifications work.

Related