Triggers
How workflows start — manual, chat, API, schedule, webhook, voice, or a vendor-specific trigger from an installed integration.
Every workflow run starts from a trigger. Pick the right trigger for the situation and the rest of the workflow can stay the same.
Built-in triggers
Start (manual / chat / API)
The default entry point. Run manually from the editor, expose a chat surface, or call by API from one unified block.
Schedule
Run on a cron expression or a simple interval (every N minutes, hourly, daily, weekly, monthly).
Webhook
Run when an external system POSTs to a Scrydon-generated URL.
Voice
Record audio, transcribe with a speech-to-text model, and surface relevant knowledge base context.
Vendor-specific triggers
Beyond the built-in triggers, many integrations contribute their own:
- GitHub — pull-request opened, issue commented, push, workflow run completed.
- Microsoft Graph — email received, calendar event, SharePoint file change.
- Atlassian — Jira issue created or updated, Confluence page edited.
- Google — Gmail message received, Calendar event created.
Each vendor's trigger options appear in the trigger picker once the vendor's integration is installed. See Vendors for the full catalogue.
Choosing a trigger
| Question | Use |
|---|---|
| Does a user explicitly start the workflow? | Start (manual or chat) |
| Does it run on a clock? | Schedule |
| Does an external system signal "run me"? | Webhook (generic) or a vendor trigger |
| Does the user interact with the workflow conversationally? | Start with chat mode |
| Does the user speak to the workflow? | Voice |
| Is the workflow called by another workflow? | Workflow block in the parent (no separate trigger needed) |
Trigger payload
Every trigger produces an input payload accessible through variable references in downstream blocks:
| Trigger | Variables |
|---|---|
| Start (manual / API) | <start.input>, <start.fieldName> (custom input fields) |
| Start (chat) | <start.input> (user message), <start.conversationId>, <start.files> |
| Schedule | No output variables — use block outputs from subsequent blocks |
| Webhook | <webhook1.payload>, <webhook1.headers>, <webhook1.method>, <webhook1.query> |
| Voice | <voice1.transcript>, <voice1.knowledgeBaseContext>, <voice1.audioUrl>, <voice1.language>, <voice1.duration> |
| Vendor trigger | Vendor-specific event fields, fully typed |
The variable prefix (start, webhook1, voice1, etc.) matches the block name you assign in the workflow editor.
Environments and testing
Workflows live in a workspace environment. New workflows start in the writable Development environment; Staging and Production are read-only (promoted) environments.
Triggers fire in every environment — what changes is which version of the workflow runs:
| Environment | Trigger runs against | Deployment required? |
|---|---|---|
| Development (writable) | The live/draft workflow — exactly what's on the canvas | No — test webhooks, API calls, and chat as you build |
| Staging / Production (read-only) | The deployed snapshot captured at promotion | Yes — an active deployment version |
This means you can call a webhook (or the API/chat trigger) against a workflow in Development to test it end to end before promoting. Once you promote to Staging or Production, the same trigger runs the deployed snapshot instead of the draft. Each environment has its own trigger URL.
Related
- Execution — what happens once the trigger fires.
- Automations — single-agent jobs with schedule or webhook triggers.
- Vendors — the catalogue of installable integrations and their triggers.