Configuring Triggers

Every workflow starts with a trigger node that defines how and when execution begins. Thallus supports four trigger modes, each suited to different automation scenarios.

Trigger modes at a glance

Mode How it starts Payload Best for
Manual User clicks Run or calls API Optional custom JSON On-demand tasks, testing
Schedule Cron expression fires None (time-based) Recurring reports, daily checks
Webhook External HTTP event received Event payload from source Real-time reactions to external events
Poll Agent periodically checks a service Discovered events Services without webhook support

Manual triggers

Manual triggers are the simplest mode — the workflow runs when you click the Run button on the workflow card or call the execution API endpoint.

You can optionally provide a custom JSON payload when starting a manual run. This payload becomes available to all downstream nodes via {{ trigger.payload }}. This is useful for parameterized workflows where the same workflow handles different inputs.

Schedule triggers

Schedule triggers run workflows on a time-based cadence defined by a cron expression. See Scheduling for detailed cron syntax, the visual builder, and timezone handling.

Key details:

  • Cron expressions use standard 5-field syntax: minute hour day-of-month month day-of-week
  • Timezone support ensures the schedule evaluates in your local time while storing next-run times in UTC
  • The scheduler periodically checks for due workflows
  • After each execution, the system calculates and stores the next run time

Example expressions:

Expression Description
0 9 * * 1-5 Weekdays at 9:00 AM
0 */4 * * * Every 4 hours
30 8 1 * * 8:30 AM on the 1st of each month
0 0 * * 0 Midnight every Sunday

Webhook triggers

Webhook triggers fire when an external service sends an HTTP event to the workflow's webhook URL. There are two approaches:

Template-based webhooks

Template-based webhooks use predefined schemas for popular services (Jira, Slack, GitHub, etc.). When you select a template:

  • The system provisions a webhook URL specific to that source type
  • Incoming events are validated against the known schema
  • Event filters let you narrow which events trigger the workflow (e.g., only issue.created events from Jira)
  • Multiple workflows can share a webhook source template, enabling shared schema learning

Custom webhooks

For services without a template, create a custom webhook source:

  • You provide a name and optional description
  • The system generates a unique webhook URL and secret for signature validation
  • You configure the external service to POST to this URL
  • The full request body becomes the trigger payload

Event filtering

Both template and custom webhooks support event filters in the trigger configuration. Filters are defined as JSON conditions that the incoming payload must match. Only events passing the filter trigger workflow execution.

Poll triggers

Poll triggers use an agent to periodically check an external service for new events. This is useful for services that don't support webhooks or when you need to monitor for specific conditions.

Configuration:

  • Agent — which integration agent to use for polling (e.g., gmail, jira, slack)
  • Interval — how often to poll, in seconds (default 300s / 5 minutes, minimum 60s)
  • Filter config — agent-specific criteria for what constitutes a new event

Deduplication:

The trigger tracks a cursor to avoid processing the same event twice. Each poll request passes this cursor to the agent, which returns only events newer than that point. Additional state (like page tokens) is stored per trigger for pagination.

Error handling:

Poll errors are tracked per trigger with the last error message stored for debugging. Persistent errors do not automatically disable the trigger, but they are visible in the workflow monitoring UI.

Source modes

Workflows can control which data sources (databases, document collections, integrations) are available during execution:

Mode Behavior
Auto The orchestrator chooses from all available sources
Suggested The system suggests sources based on past executions; user confirms
Explicit Only the specifically selected connections, collections, and integrations are used

Source mode is set at the workflow level and applies to all action nodes unless a node has its own source restrictions configured.