Skip to main content

Chaining events

A single subscription covers "when X happens, do Y". For anything longer than that — "export it, and then mark it as sent" — you chain subscriptions together.

That's what the Triggers tab on the Event actions card is for. An action can raise a brand-new event when it finishes successfully, and any subscription listening for that event takes over.

How it works​

  1. The subscription's event happens and its action runs — say, an export.
  2. The action succeeds and returns a result: whatever the export replied with.
  3. For each trigger configured on that action, SHIPM8 raises a new event with the name you gave it.
  4. That new event carries:
    • the action's result as its event data;
    • the original event message as its original data.
  5. A second subscription, listening for that trigger identifier, picks it up — with its own conditions and its own actions.

You can chain as many steps as you need, and one action can raise several triggers at once if it should set off more than one thing.

Configuring a trigger​

With the subscription in edit mode, open the Triggers tab of the Event actions card and click Add (or click an existing action's row to edit its triggers). Each entry has a single box:

  • Trigger — the identifier of the event to raise.

Use Add trigger for more entries and Remove trigger to drop one. Then create the second subscription with that same identifier as its trigger identifier.

Name your own chain events clearly

Chain events are your own invention — nothing else in SHIPM8 raises them, so you choose the name. Pick something obvious and consistent, like a $ prefix followed by your own words, so the overview reads as a sequence rather than a puzzle. Give the second subscription trigger type Generic unless its name ends in one of the words listed on Create a subscription.

Two things to watch​

A trigger only fires when the action returned something. If the action produced no result — because it failed, or because there was nothing to do — the follow-up event is not raised. That's the useful part: it means the chain naturally stops when a step didn't work, so the "mark it as sent" step can't run after a failed send.

The second step sees the first step's result, not the original record. The new event's data is what the action replied with. If the second subscription needs values from the original record, they're in the original data of the message — worth checking with an Admin notification action first, so you can see what actually arrives before you write conditions or field paths against it.

Why not just add more actions?​

Both are valid. Several actions on one subscription are simpler, and are the right choice when the steps are independent — export it and e-mail someone.

Chaining is better when the steps are genuinely sequential and the later one must only happen if the earlier one worked, because actions on a single subscription keep going after one of them fails.