Skip to main content

Trigger Nodes

Trigger nodes are the starting points of Splice workflows. They define how a workflow begins — on a schedule, in response to an inbound message or event, or on demand. Every workflow begins with a trigger node, and the trigger's output becomes the workflow's initial data.

Available Triggers​

Scheduled​

Cron​

Run a workflow automatically on a time-based schedule — hourly, daily, weekly, monthly, or on a custom cron expression. Schedules are evaluated in UTC.

Common use cases: daily status updates, weekly reports, monthly invoice runs, polling a system that has no push option.

Event-Based (HTTP)​

These triggers start a workflow from an inbound HTTP request to the workflow's public endpoint (POST /hook/{workflowId}).

Webhook​

The general-purpose HTTP trigger. Accepts JSON, XML, form data, and file uploads, supports multiple authentication strategies (Basic, Header, RSA signature), and doubles as the AS2 receiver for inbound EDI.

Common use cases: carrier callbacks, TMS updates, customer portal submissions, inbound EDI over AS2.

SiteTrax Trigger​

Starts a workflow on a SiteTrax container event (for example, a newly read container number with image and GPS).

Common use cases: gate/yard activity capture, container read validation, exception handling.

Turvo Trigger​

Starts a workflow on a Turvo shipment event (create or update), delivering the full shipment payload to the workflow.

Common use cases: shipment sync into a WMS/ERP, EDI generation from shipment activity, status-change automation.

Email​

Incoming Email​

Starts a workflow when a message arrives at a dedicated Splice inbox (<prefix>-<id>@email.splice-it.com). The parsed message — headers, body, and attachments — becomes the workflow input.

Common use cases: BOL/invoice/POD intake from attachments, onboarding partners that deliver documents by email.

Manual​

Start​

The manual entry point. Runs a workflow on demand from the Splice editor, with no schedule or external caller and no configuration.

Common use cases: development and testing, one-off jobs, ad-hoc batch processing.

Choosing a Trigger​

If the workflow should begin…Use
On a fixed scheduleCron
When an external system pushes data over HTTPWebhook
On a SiteTrax container eventSiteTrax Trigger
On a Turvo shipment eventTurvo Trigger
When an email (often with attachments) arrivesIncoming Email
On demand, by handStart

How Triggers Deliver Data​

Each trigger emits a single output keyed by the trigger node's name; downstream nodes read the initial data through that key. What the trigger carries depends on its type:

  • Cron and Start carry no inbound payload — they initiate work (query a system, list a directory) rather than consume incoming data.
  • Webhook, SiteTrax, and Turvo carry the parsed request body / event payload.
  • Incoming Email carries the parsed message (from, to, cc, subject, date, optional body, and attachment storage paths).

Security Considerations​

  • HTTP triggers are public. The /hook/{workflowId} URL (and the Incoming Email address) is a public ingress — the URL itself is not a secret. For the Webhook trigger, configure authentication (Basic, Header, or AS2). For triggers without built-in authentication, validate the payload inside the workflow before acting on it.
  • Filter downstream. Triggers such as Incoming Email, SiteTrax, and Turvo do not filter by sender or content at the node level — validate sender, subject, status, or event type in an early If/Switch node.
  • Keep ingress addresses private. Treat webhook URLs and inbound email addresses like credentials; anyone who learns them can start the workflow.

Best Practices​

  • Match the trigger to the source. Prefer a push-based trigger (Webhook, SiteTrax, Turvo, Email) when the source can notify you; reserve Cron polling for sources that can't.
  • Make runs idempotent. Retries and repeated events happen; key downstream actions on a stable identifier so re-processing is safe.
  • Use descriptive node names. The trigger output is keyed by the node name, so a clear name makes downstream references self-documenting.
  • Confirm the workflow is active. Inactive workflows are not scheduled and do not respond to inbound events.

Monitoring and Troubleshooting​

Common Issues​

  • Workflow not starting - Confirm the workflow is active and the trigger is configured (correct schedule, URL, or address).
  • Authentication failures - For the Webhook trigger, verify the configured credential matches what the caller sends.
  • Unexpected payloads - Inspect the captured trigger sample in the editor; payload shapes vary by source.

Debugging Tools​

  • Execution history - Review each run and its trigger timestamp.
  • Captured sample data - Each trigger stores its parsed payload as node sample data, which you can use to design downstream nodes.

Integration Examples​

Carrier Integration​

Carrier Webhook → Validate Shipment Data → Update TMS → Notify Customer

Scheduled Reporting​

Daily Cron → Query Database → Generate Report → Email to Stakeholders

Document Intake​

Incoming Email → Parse Attachment → Validate Data → Import to System → Send Confirmation

Shipment Automation​

Turvo Trigger → Extract Shipment Fields → Build EDI → Send to Carrier

Trigger nodes are the foundation of automated logistics workflows, enabling Splice to respond to real-world events and schedules across your supply chain operations.