Core Triggers
Use the Start block for everything originating from the editor, deploy-to-API, or deploy-to-chat experiences. Other triggers remain available for event-driven workflows:
Start
Unified entry point that supports editor runs, API deployments and chat deployments
Webhook
Receive external webhook payloads
Schedule
Cron or interval based execution
Quick Comparison
| Trigger | Start condition |
|---|---|
| Start | Editor runs, deploy-to-API requests, or chat messages |
| Schedule | Timer managed in schedule block |
| Webhook | On inbound HTTP request |
The Start block always exposes
input,conversationId, andfilesfields. Add custom fields to the input format for additional structured data.
Using Triggers
- Drop the Start block in the start slot (or an alternate trigger like Webhook/Schedule).
- Configure any required schema or auth.
- Connect the block to the rest of the workflow.
Deployments power every trigger. Update the workflow, redeploy, and all trigger entry points pick up the new snapshot. Learn more in Execution → Deployment Snapshots.
Manual Execution Priority
When you click Run in the editor, Zippy automatically selects which trigger to execute based on the following priority order:
- Start Block (highest priority)
- Schedule Triggers
- External Triggers (webhooks, integrations like Slack, Gmail, Airtable, etc.)
If your workflow has multiple triggers, the highest priority trigger will be executed. For example, if you have both a Start block and a Webhook trigger, clicking Run will execute the Start block.
External triggers with mock payloads: When external triggers (webhooks and integrations) are executed manually, Zippy automatically generates mock payloads based on the trigger's expected data structure. This ensures downstream blocks can resolve variables correctly during testing.