Triggers

Triggers define when and how a workflow starts executing. Every workflow needs at least one trigger -- it is the entry point that receives data and kicks off the automation.

Choose the trigger based on the event that should be authoritative for the workflow. API triggers are useful when your application or backend decides exactly when a run should start. Webhook triggers are better when an external provider owns the event, such as an invoice update, payment status change, CRM change, or signed document. Schedule triggers fit recurring operational work, and Slack events fit workflows that intentionally begin from a human request or channel interaction.

For finance operations, trigger design should also cover duplicate events, missing fields, and timing. External systems may retry webhooks, send events out of order, or deliver updates before related records are fully available. A reliable workflow validates the trigger payload early, stores enough context for debugging, and routes incomplete or ambiguous cases to an explicit exception path. That keeps automation fast for normal cases while preserving control when the trigger data is not ready to trust.

Before choosing a trigger, decide whether the workflow should run automatically, on a schedule, or only when a person or internal system explicitly asks it to run. That decision affects monitoring, permissions, and retry behavior. Automatic triggers need stronger guardrails because they can fire at any time. Manual or API-triggered workflows can be easier to validate during rollout because the caller controls when production data enters the workflow.

Trigger Types

Loopfour supports several trigger types, each suited to different automation patterns:

Quick Comparison

Trigger Payload

Every trigger provides a payload that downstream blocks can access. The payload structure depends on the trigger type:

• Webhook: The HTTP request body, headers, and query parameters
• Schedule: Execution metadata (timestamp, run ID, schedule name)
• Event: Platform-specific event data (e.g., Salesforce record fields, HubSpot deal properties)
• API: The request body passed in the API call

Access trigger data in downstream blocks using template variables:

{{input.customer.email}}
{{input.opportunity.amount}}
{{input.event.type}}

Supported Webhook Providers

The webhook trigger includes built-in signature verification for these providers:

Event Trigger Integrations

The event trigger connects to platform-native event systems:

Best Practices

• Use webhooks for real-time reactions to events in external systems. Webhook triggers execute immediately when the event occurs.

• Use schedules for batch processing like daily invoice syncs, weekly reports, or monthly reconciliation runs.

• Use event triggers for native platform integration when you need to react to specific record changes in Salesforce or HubSpot.

• Always validate webhook payloads. Built-in signature verification is enabled by default for supported providers. For custom webhooks, configure an auth token.

• Design idempotent workflows. Triggers may fire multiple times for the same event (especially webhooks). Use idempotency keys or deduplication logic to prevent duplicate processing.