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.body>, <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.
<start> is whichever trigger fired
<start> always refers to the trigger that started this run, whatever that trigger is called. It is the portable form, and the only one that works in a workflow with more than one trigger.
That matters because a run has exactly one trigger. If a workflow has four triggers and an alert arrives on one of them, only that one has a name for the duration of the run. A reference to any of the other three resolves to nothing:
// ❌ Breaks whenever a different trigger fires — and they take turns.
const raw = <claudestatus.body> || <signoz.body> || <generic.body>;
// ✅ One reference, correct for every trigger.
const start = <start>;
const raw = start.body !== undefined ? start.body : start.payload;Name a trigger directly only when the workflow has exactly one, or when you deliberately want a value that is present for one trigger and absent for the rest. In code, a reference that resolves to nothing becomes undefined, so <a.body> || <b.body> || {} picks whichever one fired. In text, it is left visible as written so you can see it did not resolve.
Environments and testing
Workflows live in a workspace environment. Environment names are user-defined, and each environment is configured as writable or read-only. A common setup calls these Development, Staging, and Production, but those names do not carry built-in behavior.
Triggers fire in every environment — what changes is which version of the workflow runs:
| Environment | Trigger runs against | Deployment required? |
|---|---|---|
| Any writable environment | The live/draft workflow — exactly what's on the canvas | No — test webhooks, API calls, and chat as you build |
| Any read-only environment | The deployed snapshot — the active deployment version | Yes — an active deployment version |
This means you can call a webhook (or the API/chat trigger) against a workflow in any writable environment to test it end to end before promoting. In a read-only environment, the same trigger runs the deployed snapshot instead of the draft. Each environment has its own trigger URL.
Promoting a workflow always creates a deployment snapshot in the target environment, so a promoted workflow is ready to run whether the environment is writable or read-only.
Switching an environment to read-only
Making an environment read-only changes which version every workflow in it executes: from the live draft to the deployed snapshot. A workflow that has no deployment version at that moment — for example one created directly in the environment while it was still writable — stops responding to triggers with 403 and the code WORKFLOW_NOT_DEPLOYED.
The Execution column on the Monitor page shows this per workflow: Live (draft) in a writable environment, Deployed when a snapshot exists, and Not deployed — triggers blocked when one is missing. Use the row's Deploy action to create the snapshot in place; the webhook URLs do not change.
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.