Workflow Triggers

Triggers determine when and how your workflows execute. Every workflow must have exactly one trigger node as its first node. The trigger produces the initial data that flows downstream through the rest of the workflow.

Strongly AI provides 11 trigger types covering a wide range of execution patterns, from HTTP-based triggers to time-based schedules, file system monitoring, and event-driven architectures.

---

Webhook

Receive webhooks from external services with provider-specific HMAC signature verification and security controls.

Use Cases

• GitHub push/pull request event processing
• Stripe payment and subscription notifications
• Slack message and interaction handling
• Custom webhook integrations from any service

Configuration

Setting	Description	Required
Provider	Webhook source: GitHub, Stripe, Slack, or Generic HMAC	Yes
Secret	Shared secret key for HMAC signature verification	Yes
HTTP Method	GET, POST, PUT, or DELETE	Yes
Allowed Events	Filter specific event types per provider (empty allows all)	No
IP Whitelist	Restrict access to specific IP addresses or CIDR ranges	No
Max Body Size	Maximum request body size in bytes (default: 1MB, max: 10MB)	No

Provider-Specific Signature Verification

Each provider uses its own signature header and verification method:

Provider	Signature Header	Method
GitHub	X-Hub-Signature-256	HMAC-SHA256
Stripe	Stripe-Signature	HMAC-SHA256 with timestamp
Slack	X-Slack-Signature	HMAC-SHA256
Generic	X-Webhook-Signature	HMAC

Security Features

The webhook trigger includes the following security measures:

• HMAC signature verification with timing-safe comparison
• Replay attack prevention via timestamp validation
• Built-in rate limiting (10 requests/minute, 100 requests/hour)
• Configurable request size limits
• Optional IP whitelisting with CIDR support
• Generic error messages to prevent detail leakage

Outputs

Field	Type	Description
provider	string	Webhook provider (github, stripe, slack, generic)
event_type	string	Event type extracted from provider-specific header
headers	object	Request headers
body	object	Raw request body
parsed_data	object	Provider-specific parsed data
method	string	HTTP method
clientIP	string	Client IP address
signatureVerified	boolean	Signature verification status
request_s3_url	string	S3 URL for large request data (> 10KB)

Webhook URL Pattern

/api/webhook/{workflowId}

Signature Verification

The webhook secret is required for all providers. Always configure a strong, unique secret for each webhook integration to ensure requests come from trusted sources.

---

Schedule

Trigger workflows on a time-based schedule. Scheduled workflows are deployed as scheduled jobs.

Use Cases

• Daily report generation
• Periodic data synchronization
• Scheduled cleanup and maintenance tasks
• Batch processing jobs on recurring intervals

Schedule Types

1. Interval-Based

Run at a fixed interval specified in minutes (1 to 10,080 minutes / 7 days):

Interval	Example Use Case
Every 5 minutes	Real-time monitoring
Every 60 minutes	Hourly data aggregation
Every 360 minutes	Periodic cleanup

2. Daily Execution

Run once per day at a specific time in 24-hour format (e.g., 09:00).

3. Cron Expression

Use standard cron syntax for advanced scheduling:

# Every weekday at 9 AM
0 9 * * 1-5

# First day of every month at midnight
0 0 1 * *

# Every 30 minutes during business hours
*/30 9-17 * * 1-5

# Quarterly on the 1st at 6 AM
0 6 1 */3 *

Cron Format Reference

+-------------- minute (0 - 59)
| +------------ hour (0 - 23)
| | +---------- day of month (1 - 31)
| | | +-------- month (1 - 12)
| | | | +------ day of week (0 - 6) (Sunday=0)
| | | | |
* * * * *

Configuration

Setting	Description	Required
Schedule Type	Interval, Daily, or Cron	Yes
Interval (minutes)	Run frequency when using interval mode (1-10,080)	Conditional
Daily Time	Time in 24-hour format when using daily mode	Conditional
Cron Expression	Standard cron expression when using cron mode	Conditional
Timezone	Execution timezone (UTC, Eastern, Central, Pacific, London, Tokyo)	Yes
Enabled	Whether the schedule is active	No

Outputs

Field	Type	Description
trigger_time	string	ISO timestamp when triggered (UTC)
local_time	string	ISO timestamp in configured timezone
cron_expression	string	The cron expression used
timezone	string	Timezone used for execution
next_execution	string	ISO timestamp of next scheduled execution
execution_context	object	Context with day_of_week, date, and time

Timezone Configuration

Always specify the correct timezone for scheduled workflows. The schedule executes based on the configured timezone, which may differ from your local time or server time.

---

REST API Trigger

Expose a workflow as an authenticated REST API endpoint with role-based access control and input validation.

Use Cases

• Custom API endpoints for internal microservices
• Mobile and web application backends
• Third-party integration endpoints
• Synchronous request-response workflows

Configuration

Setting	Description	Required
Endpoint Path	URL path for the API (e.g., /api/v1/my-workflow)	Yes
HTTP Method	POST, GET, PUT, DELETE, PATCH, or Any Method	Yes
Require Authentication	Whether callers must be authenticated	No (default: true)
Allowed Roles	Roles permitted to call the endpoint (owner, admin, user, viewer)	No
Expected Inputs	Input field definitions with type and validation	No
Default Query Parameters	Default query parameters as JSON	No

Expected Inputs Schema

Define expected input fields with validation:

Property	Description
Name	Field name (e.g., userId)
Type	Data type: string, number, integer, boolean, array, object
Required	Whether the field is mandatory
Default	Default value if not provided
Description	Field description for API documentation

Outputs

Field	Type	Description
_request	object	Full request context
_request.endpoint	string	Matched endpoint path
_request.method	string	HTTP method
_request.headers	object	Request headers
_request.query	object	Query parameters
_request.path_params	object	URL path parameters
_request.user	object	Authenticated user info (userId, email, roles)
_request.client_ip	string	Client IP address
_request.userAgent	string	User agent string

Response Handling

Use the webhook-response destination node to send structured responses back to the API caller. The workflow output returned by the webhook-response node becomes the HTTP response body.

---

Chat Trigger

Trigger workflows from chat and conversational interfaces with automatic conversation history management.

Use Cases

• Conversational AI assistants
• Customer support chatbots
• Interactive Q&A workflows
• Multi-turn dialogue systems

Configuration

Setting	Description	Required
Session ID Field	Input field name containing the session/conversation ID	No (default: sessionId)
Message Field	Input field name containing the message content	No (default: message)
Include History	Include previous messages in the conversation	No (default: true)
Max History Length	Maximum number of history messages to include (1-50)	No (default: 10)

Inputs

Field	Type	Description
message	string	Chat message content
sessionId	string	Session/conversation identifier
userId	string	User identifier
userName	string	User display name
channel	string	Channel identifier (web, slack, etc.)
timestamp	string	Message timestamp

Outputs

Field	Type	Description
message	string	Message content
sessionId	string	Session/conversation ID
history	array	Previous conversation messages
currentMessage	object	Current message with role, content, and timestamp
userId	string	User identifier
userName	string	User display name
channel	string	Channel identifier
messageMetadata	object	Metadata including timestamp, historyLength, isFirstMessage

---

Email Trigger

Trigger workflows when new emails arrive by monitoring an IMAP inbox. Supports filtering by search criteria and automatic mark-as-read to prevent reprocessing.

Use Cases

• Automated email processing and routing
• Support ticket creation from incoming emails
• Invoice and attachment extraction
• Email-driven approval workflows

Configuration

Setting	Description	Required
IMAP Host	IMAP server hostname (e.g., imap.gmail.com)	Yes
Port	IMAP port (993 for SSL, 143 for non-SSL)	No (default: 993)
Use SSL	Connect using SSL/TLS	No (default: true)
Username	Email account username	Yes
Password	Email account password or app-specific password (encrypted)	Yes
Mailbox	Mailbox/folder to monitor	No (default: INBOX)
Search Criteria	IMAP search filter	No (default: Unread)
Mark as Read	Mark fetched emails as read to avoid reprocessing	No (default: true)
Max Emails	Maximum emails to fetch per trigger (1-100)	No (default: 10)

Search Criteria Options

Value	Description
UNSEEN	Unread emails only
ALL	All emails
FLAGGED	Flagged/starred emails
RECENT	Recent emails
SENTON	Today's emails

Outputs

Field	Type	Description
emails	array	Array of email objects with id, subject, from, to, bodyText, bodyHtml, attachments
count	number	Number of emails fetched
mailbox	string	Mailbox name that was searched
searchCriteria	string	IMAP search criteria used

---

Form Trigger

Accept public form submissions with configurable fields, file uploads, reCAPTCHA protection, and rate limiting.

Use Cases

• Contact and inquiry forms
• File upload portals
• Survey and feedback collection
• Support ticket submission
• Application and registration workflows

Configuration

Setting	Description	Required
Form ID	Unique identifier for this form	No (default: form)
Form Title	Display name for the form	No
Description	Form description or instructions	No
Enable CAPTCHA	Require reCAPTCHA v3 verification	No (default: true)
reCAPTCHA Secret Key	Google reCAPTCHA v3 secret key (encrypted)	Conditional
CAPTCHA Score Threshold	Minimum reCAPTCHA score (0.0-1.0)	No (default: 0.5)
Rate Limit (per hour)	Maximum submissions per hour from same IP (1-1000)	No (default: 10)
Max File Size (MB)	Maximum file upload size in megabytes (1-100)	No (default: 10)
Form Fields	Field definitions with validation rules	No
Validation Rules	Custom validation rules per field (JSON)	No
Success Message	Confirmation text after submission	No
Redirect URL	Post-submission redirect URL	No
Send Email Notification	Send email on form submission	No (default: false)
Email To	Notification recipient email address	Conditional

Supported Field Types

Type	Description
text	Single-line text input
email	Email address with format validation
number	Numeric input
boolean	Checkbox
file	File upload
textarea	Multi-line text
select	Dropdown selection
date	Date picker
url	URL with format validation
tel	Phone number

Each field supports a name, label, required flag, and placeholder text.

CAPTCHA Protection

The form trigger supports Google reCAPTCHA v3, which provides score-based bot detection without user interaction. Configure a score threshold between 0.0 and 1.0 to control sensitivity. Obtain reCAPTCHA keys from Google reCAPTCHA Admin.

Outputs

Field	Type	Description
formId	string	Form identifier
form_data	object	Submitted form field values
files	array	Processed uploaded files with S3 URLs
validation	object	Validation results with is_valid, errors, warnings
submission_metadata	object	Submission context (timestamp, ipAddress, userAgent, referrer)
form_data_s3_url	string	S3 URL for large form data (if > 5KB)

---

File Trigger

Trigger workflows based on local file system changes. Supports monitoring directories for created, modified, or deleted files with glob pattern matching.

Use Cases

• Process new files uploaded to a directory
• Detect configuration file changes
• Monitor data landing zones for new CSV/JSON files
• File integrity monitoring via hash comparison

Configuration

Setting	Description	Required
Watch Path	File or directory path to monitor	Yes
Operation	Check Changes, List Files, Get File Info, Get File Hash, or Watch Directory	Yes
Trigger On	File Created, File Modified, File Deleted, or Any Change	No (default: Any Change)

Operations

Operation	Description
Check Changes	Compare current state against previous state to detect changes
List Files	List all files matching the path and pattern
Get File Info	Get metadata for a specific file (name, size, timestamps)
Get File Hash	Compute hash of a file (MD5, SHA1, SHA256, SHA512)
Watch Directory	Create a snapshot of directory state for future comparison

Inputs

Field	Type	Description
watchPath	string	Path to file or directory to monitor
pattern	string	File pattern using glob syntax (e.g., *.csv)
previousState	object	Previous state snapshot for change detection
recursive	boolean	Scan directories recursively
filePath	string	Specific file path for get_file_info/get_file_hash
algorithm	string	Hash algorithm: md5, sha1, sha256, sha512

Outputs (Check Changes)

Field	Type	Description
hasChanges	boolean	Whether changes were detected
triggeredFiles	array	Array of changed file objects
changes	object	Changes grouped by type: created, modified, deleted
currentState	object	Current state snapshot for next comparison

---

RSS Feed Trigger

Trigger workflows when new RSS or Atom feed items appear. Tracks previously seen items to process only new entries.

Use Cases

• News and content aggregation
• Blog post monitoring and notifications
• Competitor content tracking
• Automated content curation pipelines

Configuration

Setting	Description	Required
Feed URL	URL of the RSS or Atom feed	Yes
Max Items	Maximum items to fetch per trigger (1-100)	No (default: 20)
Only New Items	Only return items not seen in previous triggers	No (default: true)
Include Full Content	Include full article content when available	No (default: true)

Outputs

Field	Type	Description
items	array	Feed items with id, title, link, published, author, summary, content, categories
count	number	Number of items returned
feedTitle	string	Title of the feed
feedLink	string	Main link of the feed
feedDescription	string	Description of the feed
feedUrl	string	URL of the feed that was fetched

---

SSE Trigger

Trigger workflows when Server-Sent Events are received from an external SSE endpoint. Supports automatic reconnection and event type filtering.

Use Cases

• Real-time event stream processing
• Live data feed consumption
• Server push notification handling
• Streaming API integration

Configuration

Setting	Description	Required
SSE Endpoint URL	URL of the SSE endpoint to connect to	Yes
Event Types	Comma-separated event types to listen for (empty listens to all)	No
Headers	Custom headers for the SSE connection (key-value pairs)	No
Auto Reconnect	Automatically reconnect on connection loss	No (default: true)
Reconnect Delay (ms)	Delay before reconnection attempt	No (default: 3000)

Outputs

Field	Type	Description
eventType	string	SSE event type
eventId	string	SSE event ID
data	any	Parsed event data (JSON if valid, otherwise string)
rawData	string	Original raw data string
timestamp	string	Event timestamp
retry	number	SSE retry value in milliseconds

---

Error Trigger

Trigger a workflow when errors occur in other workflow executions. Enables centralized error handling, alerting, and recovery workflows.

Use Cases

• Centralized error logging and alerting
• Automated incident creation from workflow failures
• Error recovery and retry orchestration
• Severity-based escalation workflows

Configuration

Setting	Description	Required
Filter by Workflow IDs	Only trigger for errors from specific workflows (empty = all)	No
Filter by Node Types	Only trigger for errors from specific node types (empty = all)	No
Filter by Severity	Only trigger for specific severities: Warning, Error, Critical (empty = all)	No
Include Stack Trace	Include full error stack trace in output	No (default: true)

Outputs

Field	Type	Description
error	object	Error details with message, type, code, severity, timestamp, stackTrace
workflow	object	Workflow context with workflowId, workflowName, executionId
node	object	Node context with nodeId, nodeType, nodeName
context	object	Additional context data passed through
inputData	object	Input data that caused the error
errorMetadata	object	Metadata with severity and hasStackTrace flag

---

Multi-Modal Input

Accept mixed media types as workflow input, including text, images, audio, and files in a single request.

Use Cases

• AI workflows requiring multiple input types (text + image)
• Document processing with mixed media
• Multi-format data ingestion pipelines
• Interactive applications with diverse input types

Configuration

Setting	Description	Required
Accepted Types	Array of accepted media types (text, image, audio, file)	No (default: all)
Max File Size (MB)	Maximum file size in megabytes (1-100)	No (default: 10)
Max Items	Maximum number of input items (1-50)	No (default: 10)

Inputs

Field	Type	Description
items	array	Array of input items with mixed media types
text	string	Text input
image	string	Image as base64 or URL
audio	string	Audio as base64 or file path
file	string	File as base64 or file path

Outputs

Field	Type	Description
items	array	Processed input items with type, content, path, and metadata
inputSummary	object	Summary of received inputs by type
textContent	string	Combined text content
mediaItems	array	Non-text media items

---

Architecture Notes

Trigger Execution Model

Triggers are the entry point for every workflow execution. Each workflow has exactly one trigger node, and the trigger type determines how the workflow is invoked:

• Request-based triggers (webhook, REST API, chat, form, multi-modal input) are invoked through the platform backend when an HTTP request arrives at the appropriate endpoint.
• Schedule triggers are deployed as scheduled jobs by the platform. When the schedule fires, it submits an execution request to the backend.
• Polling triggers (email, RSS, file) check for new data at execution time and produce results for downstream nodes.
• Event-driven triggers (error, SSE) react to events from other systems or workflows.

Large Payload Handling

Several triggers (webhook, form, REST API) automatically upload large payloads to S3 when they exceed size thresholds. The S3 URL is provided in the output so downstream nodes can retrieve the full data when needed.

---

Common Patterns

Webhook Event Routing

Webhook Trigger (GitHub)
  -> Switch-Case (Route by event_type)
    -> [push] Process push event
    -> [pull_request] Process PR event
    -> [issues] Process issue event

Scheduled Batch Processing

Schedule Trigger (Daily at 2 AM)
  -> REST API Call (Fetch records)
  -> Loop (Process each record)
  -> MongoDB Destination (Update database)
  -> SMTP (Send completion report)

Form Submission Processing

Form Trigger (with CAPTCHA)
  -> MongoDB Destination (Store submission)
  -> SMTP (Send confirmation email)
  -> Webhook Response (Return success message)

Centralized Error Handling

Error Trigger (Filter: severity = critical)
  -> Switch-Case (Route by error type)
    -> [ConnectionError] Retry workflow
    -> [TimeoutError] Alert on-call team
    -> [default] Log to monitoring system

---

Troubleshooting

Webhook Not Triggering

• Verify the webhook URL matches the pattern /api/webhook/{workflowId}
• Confirm the HMAC secret matches what the external service is configured with
• Check that the workflow is deployed and active
• If using IP whitelisting, verify the sender IP is in the allowed range
• Review execution logs for signature verification failures

Schedule Not Running

• Verify the workflow is deployed (schedule triggers use Kubernetes CronJobs)
• Confirm timezone settings are correct for the intended execution time
• Check that the enabled flag is set to true
• Review CronJob status in the Kubernetes cluster
• Validate the cron expression syntax

REST API Returning Errors

• Verify authentication credentials and user roles match the allowedRoles configuration
• Check that the request body matches the expectedInputs schema
• Ensure the HTTP method matches the configured method
• Confirm the workflow is deployed and the endpoint path is correct

Email Trigger Not Processing

• Test IMAP connectivity with the configured host and port
• Verify credentials (use app-specific passwords for Gmail)
• Confirm SSL settings match the server requirements
• Check that the search criteria matches available emails
• Verify the mailbox name is correct

---

Next Steps

• Configure workflow nodes
• Test your workflows
• Deploy to production
• See workflow examples