Skip to main content

Action types

Every event action has a type, which decides what it actually does and which settings it asks for. There are eight, and this page explains each one in plain terms. The exact values that go into the boxes are specific to your setup — that's the part to work out with SHIPM8 support.

Two settings come back in most of the types, so they're worth explaining once:

  • Content module and Content type — together these say which kind of record the action works with. They're the same internal codes used throughout content distribution and custom data (for example the module for your own objects, or the code of an external system such as Exact Online).
  • Object id path — where in the event's data to find the ID of the record to act on. The event carries a whole record with it, and this tells the action which part of it identifies the record. It can point at one ID or at a list.

Admin notification​

Sends an e-mail. The subject and body are written as templates, so they can quote values from the event — "Invoice 2026-0142 for Acme was finalised".

Settings: Subject, Body, To address.

Use it to keep an eye on things, and especially to see what an event actually contains while you're building a subscription: send yourself the raw event, read it, then write your conditions and paths against what really arrived.

note

This is the only action type that doesn't touch your data, which makes it the safe one to experiment with.

Content distribution export​

Hands a record to an export. It looks up the record by its ID and runs it through content distribution, which is how SHIPM8 pushes data to bookkeeping systems and other external services. This is the action behind "when an invoice is finalised, send it to Exact Online".

Settings: Content module, Content type, Object id path, Search fields path, and Required data.

  • Search fields path — optional. Where in the event data to find search criteria that came along with the event, instead of a record ID.
  • Required data — optional. A list describing extra, related data the export needs (for example the customer behind an invoice). Each entry has a mapping key, a field, a set of requested fields, and can have children and filtering of its own. This mirrors the required data concept in Content distribution.

Content distribution export additional data​

The same idea, but for events that aren't about a stored record. Instead of looking a record up by ID, this variant passes the event's own data straight into the export. It's what you use for incoming webhooks and other events that carry their payload with them.

Settings: Content module, Content type, Search fields path, Search fields, and Required data.

  • Search fields — unlike the plain export, you can define search criteria here by hand: a field name, an operator, a value, and whether to search in custom content. Use it to find the matching record in SHIPM8 from what the external system sent.

Content distribution distribute​

Produces and delivers a document. Where export hands data to a service, distribute runs an export template and sends the result — a PDF, an e-mail, a message to a connected system.

Settings: Content module, Content type, Object id path, Template id.

Template id is the numeric ID of the export template to use. You'll find it on the template itself in Content distribution.

Content distribution distribute notification​

Distribute, plus a message and its recipients. Use this when the automation has to send something to specific people rather than following the template's own delivery settings.

Settings: everything from distribute, plus Subject, Body, Distribution source data, and a list of Recipients.

  • Subject and Body are templates, so they can quote values from the event.
  • Distribution source data decides which data travels with the message:
    • None — no extra data.
    • Only event data — the record the event was about. The usual choice.
    • Only original data — the record as it was before the change.
    • Queue message — everything, including both versions and the timestamp.
  • Each Recipient has an Address, a Display name, a Document type and a Distribution service (how it's delivered — e-mail, or a connected service).

Content distribution import​

Brings data into SHIPM8. It takes the event's data and runs it through an import definition, which maps the incoming fields onto SHIPM8 records. This is the counterpart to export: typically used with an incoming webhook, where an external system pushes a change and you want it stored.

Settings: Import definition code (the code of the import definition to run) and Source type (what kind of source the data came from).

Custom content update​

Writes values into a record's fields. The action finds the record and sets one or more fields on it.

Settings: Content module, Content type, Object id path, and Fields to update.

Each entry under Fields to update is a pair:

  • Field — which field to write to.
  • Value — what to write. This is a template, so it can be a fixed value or something built from the event, such as copying a number from the record that changed.

Use it for bookkeeping-style automations: stamp a status, copy a reference across, mark a record as handled. A field with an empty result is skipped rather than cleared.

Mind the loop

Updating a record raises an update event of its own. If a subscription on …_update updates the same kind of record, it can set itself off again. Use conditions to make sure the action can only apply once.

Invoice flow execution​

Starts an invoice flow. The event's data is handed to the flow as its source data, so the flow can build invoices from it.

Setting: Flow system code — the system code of the invoice flow to run, which you'll find on the flow in Invoice flows.

Use it for "when the job is completed, invoice it": the event marks the work as done, and the flow turns it into an invoice. The run appears in the invoice flow's own execution history, marked as started by an event handler subscription.