Skip to main content

Monitoring and troubleshooting

Automation is invisible by nature: when it works you don't notice, and when it doesn't, nothing happens at all. This page is about seeing what's going on.

What SHIPM8 records​

Every time an event matches one of your subscriptions, SHIPM8 writes an execution log entry, whether the run succeeded or not. It holds:

  • which subscription matched, and which event set it off;
  • when it ran and how long it took;
  • the outcome — success, partial success (some actions worked, some didn't), or failed;
  • a line per action, with its own timing, outcome and any error message;
  • the data that came in, and the result that went out.

Events that match no subscription are not logged — there's nothing to report.

This log is kept on the SHIPM8 side, so ask support if you need to look something up. Give them the subscription's name or trigger identifier and roughly when it should have run, and they can tell you whether the event arrived, whether it matched, and what each action did.

Watching it yourself​

The practical way to keep an eye on an automation is to add an Admin notification action to it (see Action types). It e-mails you whenever the subscription runs, and because the subject and body are templates, you can include the values you care about. It's also the fastest way to see the shape of the event data while you're building conditions and field paths.

Keep it for a while after you go live, then remove it once you trust the automation.

When nothing happens​

Almost every "my subscription doesn't run" turns out to be one of these, in rough order of likelihood:

  1. The trigger identifier doesn't match. It's free text, so a typo, a missing $, or a wrong object system code means the subscription is simply never found. Check it character by character against Event types.
  2. The trigger type doesn't match the identifier. Both have to line up — …_add needs Create, …_finalized needs Generic, and so on. The table on Create a subscription shows which is which.
  3. The subscription is outside its active period. A Starts on in the future or an Ends on in the past switches it off silently.
  4. A condition rules it out. Conditions are strict: a field path that doesn't exist in the event data makes the condition fail rather than being ignored. Send yourself the raw event with an Admin notification action and compare.
  5. The event never happened. Not every change in the app raises an event — check the event actually exists for the moment you have in mind.
  6. The action has no settings. An action whose values are empty does nothing.

When something happens, but not what you expected​

  • An action failed but the others ran. That's by design: all actions are attempted. If the later step must only run when the earlier one worked, split them and use chaining instead.
  • A follow-up event never fired. Triggers only fire when the action returned a result. No result — because the action failed or had nothing to do — means no follow-up.
  • It ran more times than you expected. Some events fire repeatedly for the same record: port-visit times are corrected over and over, and an action that updates a record can set off its own update event. Conditions are the fix.
  • It ran later than expected. Everything here runs in the background, so give it a moment. Consistently long delays are worth reporting.

Before you change a live subscription​

  • Note down the settings you're replacing — switching an action's type clears its configuration.
  • Prefer an Ends on date over deleting: it switches the automation off but keeps the configuration, so you can put it back.
  • Deleting a subscription deletes all of its actions with it.