Manual, Webhook, And Scheduled Workflows

Some workflows are started by app events. Others can be triggered manually, through a webhook endpoint, or on a schedule when those options are available.

Choose the trigger mode based on who or what should start the work. Manual runs are controlled by a user, webhook runs are controlled by an external system, and scheduled runs are controlled by time.

Manual Runs

Use manual runs to test a workflow or run a controlled automation on demand. Review the run detail immediately after triggering it.

Manual runs are best for one-off cleanup, manager-approved actions, and testing a workflow with a known record. Before running manually, confirm the workflow is using the correct record, required fields exist, and actions will not send duplicate customer messages.

Use manual runs sparingly for customer-facing or finance actions. A manual run can still create records, send messages, or update statuses.

Before triggering a manual run, write down the expected output. Compare the run detail against that expectation immediately after the run.

Webhook Endpoints

If the builder can create a webhook endpoint, copy the endpoint and secret after creation. Store the secret securely and use it to verify incoming requests.

Use webhook workflows when another system should start the automation. Keep the webhook URL private, store the secret in the sending system, and send only the fields the workflow needs. Test with a single request first and review the run detail payload before connecting the production sender.

If webhook runs do not start, confirm the endpoint URL, request method, secret, content type, and payload shape from the sending system.

Rotate the webhook secret if it was shared in chat, email, logs, or a public document. Treat it like an API credential.

Ask the sending system to include a stable reference ID when possible. It makes duplicate detection, run review, and support follow-up much easier.

Scheduled Runs

For scheduled workflows, review the schedule carefully before publishing. A schedule can create repeated runs without user interaction.

Scheduled workflows are useful for reminders, recurring checks, follow-up creation, and periodic summaries. Before publishing, confirm the timezone, frequency, active status, and whether the workflow can safely run more than once.

For scheduled workflows, add a clear owner. Someone should know why the schedule exists and when to pause it during holidays, process changes, or data cleanup.

Review scheduled workflows after timezone changes, holiday schedules, billing cutoffs, and major imports. A correct schedule can still produce bad output if the underlying data changed.

If a scheduled workflow creates customer-facing messages, add a pause process for holidays, incidents, and data cleanup windows. Time-based automation should not continue blindly when the source process is paused.

Safety Checks

Before enabling any manual, webhook, or scheduled workflow:

1. Run a simulation when available.
2. Test with one record or one webhook payload.
3. Review the run detail.
4. Confirm no duplicate records, emails, or status changes were created.
5. Publish only after the first run matches the expected outcome.

For customer-facing workflows, confirm notification templates, recipients, and deduplication behavior before enabling repeated runs.

Trigger Mode Checklist

• Use manual when a person should decide each run.
• Use webhook when an external system owns the event.
• Use schedule when the timing, not a record event, should start the work.
• Test one safe run before broad usage.
• Review run details after the first production run.

Related Docs

• Save And Publish Workflows
• Workflow Runs
• Webhook Subscriptions