Triggers

A trigger answers two questions: what starts the work, and which workflow runs next.

Open Triggers to search, sort, enable, and inspect every trigger in the organization. Each row shows its type, target workflow, run count, and most recent activity.

Create a trigger

Select New Trigger, choose a type, and pick the target workflow. You can create a workflow from the same dialog if it does not exist yet.

The quick-create flow supports the most common entry points:

Trigger	Use it for
Webhook	HTTP requests from an app, provider, or command line.
Schedule	Work that runs on a recurring clock.
Form	A hosted form that runs a workflow when someone submits it.

For event triggers and specialized types, open the workflow builder and add the trigger there.

Each trigger points to one workflow. A workflow can have several triggers—for example, a webhook for immediate work and a schedule for reconciliation.

Webhooks

A webhook gives the workflow an HTTP endpoint. Use it to receive provider events, expose a small API, or start work from another system.

After you create it, configure:

• Method — GET, POST, PUT, PATCH, or DELETE.
• Authentication — require the generated secret when the endpoint should not be public.
• Expose errors — return failure details to the caller when that is appropriate for the integration.

When authentication is enabled, send the secret as a bearer token:

curl https://run.quickflo.app/w/your-endpoint \
  -H "Authorization: Bearer $WEBHOOK_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"customerId":"cus_123"}'

Top-level JSON fields are available on initial. Request metadata stays under initial.webhook:

{{ initial.customerId }}
{{ initial.webhook.query.page }}
{{ initial.webhook.headers['x-request-id'] }}
{{ initial.webhook.files }}

Return a response

Without a Return step, the webhook queues the workflow and replies immediately. Add a Return step when the caller needs to wait for a result.

The Return step can send:

• JSON fields;
• raw text, HTML, or XML;
• a file download;
• a status code and custom response headers.

Keep synchronous webhook workflows short. If the work can take a while, acknowledge the request and deliver the result later through a callback or another workflow.

When the caller waits for a response

Adding a webhook response to a Return step makes the workflow synchronous. The caller’s HTTP request stays open while the workflow runs, then receives the status, headers, and body from the Return step.

This works well for short, predictable request-response workflows. Keep these caveats in mind:

• Each waiting request uses live execution capacity until the workflow returns. Sudden bursts may be slower while additional capacity starts.
• If synchronous capacity is temporarily full, QuickFlo returns 503 Service Unavailable. When the response includes Retry-After and the code SYNC_CAPACITY_EXHAUSTED, wait for that interval and retry—the workflow did not start.
• If QuickFlo returns 502 Bad Gateway with the code SYNC_EXECUTION_OUTCOME_UNKNOWN, the workflow may have started. Check the included statusUrl before retrying so you do not create a duplicate execution.
• The calling system should use a timeout longer than the workflow’s normal execution time and support retrying temporary failures.

Use asynchronous execution for bursty or longer work

If the caller does not need the workflow’s result in the same HTTP response, use an asynchronous webhook workflow instead. QuickFlo can acknowledge it with 202 Accepted and an execution ID, while the workflow waits for available execution capacity in the background.

Schedules

A schedule runs the target workflow from a five-field cron expression. Choose a timezone so the schedule remains clear through daylight-saving changes.

Expression	Runs
0 6 * * *	Every day at 6:00 AM.
0 9 * * 1-5	Weekdays at 9:00 AM.
*/15 * * * *	Every 15 minutes.
0 0 1 * *	The first day of each month.

You can also choose an environment and provide initial data. This lets one workflow serve several schedules with different inputs:

{
  "reportType": "daily",
  "region": "east"
}

Use descriptive names such as daily-account-summary or reconcile-every-15-minutes. The name should explain the purpose, not repeat the cron expression.

Forms and chat

Form triggers publish a hosted page and run the workflow on submission. Use the form builder for fields, validation, file uploads, access controls, and response screens.

Start with Form Triggers. If the page should be conversational, continue to Chat Agents and Chat Triggers.

Events

Event triggers listen to a connected service and start a workflow when a matching event arrives. Available events depend on the connection and integration.

Add event triggers from the workflow builder. After a test event arrives, open Executions to inspect the exact payload before writing templates against it.

Tip

Test the trigger before building deep workflow logic. A single Log or Return step is enough to prove the endpoint, schedule, form, or event payload.

Operate triggers

The Triggers page is the source of truth for what can start work. Search by name, browse by type, and use the row menu to edit, disable, or inspect a trigger.

When a trigger appears healthy but nothing runs:

1. Check whether it is disabled.
2. Confirm the target workflow.
3. Look for trigger activity in Platform Logs.
4. Open Executions if a run was created.