Bosca / Scripts

Triggers

Run on what happens

Some logic shouldn't wait to be asked for — it should just happen when something does. Drop a script into a triggered pipeline and it runs on the event, every time it fires.

Run on an event

Fired by a triggered pipeline

To run a script when something happens, wire it into a pipeline that's triggered by that event. Pipelines watches for the event and fires the flow; an Execute Script node runs your script — no polling, no glue in between.

  • A pipeline triggered by an event carries an Execute Script node.
  • When the event fires, the pipeline runs, and your script with it.
  • Pipelines handles the watching and the wiring; the script does the work.
event → script
event · content.published
pipeline · on-publish
execute script · welcome-email

The event in hand

The payload comes with it

When a trigger runs, the script is handed what happened: the event's name and its full payload, as typed JSON on the script's input. Read the id that changed, the new state, whatever the event carried — and act on it.

  • The event name and payload arrive as the script's input.
  • Reach the same platform services any script can.
  • It runs as a service account, or the principal you configure.
input
{
  "eventName": "content.metadata.state",
  "eventPayload": {
    "id": "9f3c…",
    "state": "published"
  }
}

Off the main path

It never holds anything up

Triggers run asynchronously, on a worker. The operation that fired the event — a publish, an update — finishes without waiting on them. And if a trigger fails, it's retried with backoff before the failure is recorded, so a transient blip doesn't lose the work.

  • The originating operation completes without waiting for triggers.
  • Failures retry with backoff up to a bound, then are logged.
  • Work runs on the job queue, not inline on the request.
flow
document publisheddone
trigger enqueuedasync
runs on a worker retries

Keep exploring

More on Scripts