Webhooks, Scheduling, and Execution Triggers
Triggers and Scheduling
Fusion scenarios start via triggers: polling (scheduled) or instant (webhook). Polling triggers check for new data at intervals (e.g., every 15 minutes). Webhooks provide a URL that apps call to start the scenario immediately. Scheduling settings control polling frequency, start time, and days. Webhook payloads are parsed as bundles; you can define webhook responses for synchronous calls. Custom webhooks allow defining expected data structure.
Execution Details
- Execution history logs each run, including bundles and operations.
- Cycles determine how many times a trigger runs per execution (for polling).
- Sequential processing ensures bundles are processed one at a time.
- Webhook security: Use secret or signature verification to authenticate calls.
Traps in Questions
- Polling vs. webhook: Polling runs on schedule; webhooks run on demand. Confusing them leads to latency issues.
- Webhook URL: Each webhook has a unique URL; changing it requires updating the source.
- Cycle limits: Too many cycles can cause timeouts; balance frequency and data volume.
- Webhook response: Only available for webhooks, not polling triggers.
Worked Example / Rule of Thumb
Rule of thumb: "Use webhooks for real-time, polling for batch." For example, a Workfront webhook triggers a scenario when a project is created, immediately creating a Slack channel. For daily syncs, use a polling trigger scheduled at 8 AM.