Triggers and Runs

Workflow trigger methods are configured in Workflow Settings. Drafts can be debugged before publishing; formal invocations require the workflow to be published.

Manual and API Runs

Select Run in the editor, fill in the input variables, and start. For API runs, use:

curl -X POST "$CLOUISLE_API/api/v1/workflows/<workflow_id>/run" \
  -H "Authorization: Bearer $CLOUISLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"inputs":{"query":"检查订单状态"}}'

The inputs in the request body defaults to an empty object. The response returns a run ID; use the run query interface to get the status and result.

Webhook

In Workflow Settings, select Webhook.
After saving, a Webhook Token and URL are generated.
On the Access API page, copy the URL and call it with API Key Bearer authentication.
The request JSON directly provides the workflow input fields.

Webhook workflows must be published with the corresponding trigger enabled. The initial response contains the run ID, status, and stream_url; connecting to that URL shows node events via SSE.

curl -X POST "$CLOUISLE_API/api/v1/workflows/webhook/<webhook_token>" \
  -H "Authorization: Bearer $CLOUISLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"检查订单状态"}'

In Workflow Settings > Trigger, select Scheduled Task; the UI configures an interval, daily, weekly, monthly, or a custom Cron schedule. The frequency is converted into a standard cron expression (minute hour day month weekday, e.g. 0 9 * * 1-5 for weekdays at 9 AM), with interval presets of 5/10/15/30 minutes and 1/2/3/6/12 hours.

Saving the configuration does not make it run

The backend does implement the scheduling logic: workflow.check_scheduled (backend/app/services/workflow/tasks.py) selects published workflows with trigger_type=cron, uses croniter to test whether the current minute matches the expression, and fires a run with empty inputs {} attributed to the workflow creator.

But no supplied deployment schedules it, for three separate reasons that all have to be solved:

Not in the include list: the celery_app include list in backend/app/core/celery.py does not contain app.services.workflow.tasks, so the task is not registered with the worker by default.
Not in the Beat schedule: the beat_schedule in the same file only holds usage resets, API-key/password expiry checks, sandbox session cleanup, and the lost-AgentRun sweep — there is no workflow.check_scheduled. The supplied Beat container (the beat service in Compose/Helm/K8s, command python main.py beat) runs only that table.
Key mismatch: the scheduling task reads trigger_config["cron"], while the Workflow Settings form writes trigger_config["cron_expression"]. Even once scheduled, an expression saved through the UI is never matched.

No task_routes pattern matches the task either, so it lands on the default queue — confirm a worker consumes that queue, or set options.queue on the Beat entry.

Enabling Cron in a custom deployment

Add app.services.workflow.tasks to the celery_app include list, or import the module when the worker starts.
Add a beat_schedule entry (once a minute is the intended cadence):

app/core/celery.py

celery_app.conf.beat_schedule["workflow-check-scheduled"] = {
    "task": "workflow.check_scheduled",
    "schedule": crontab(minute="*"),
}

Align the expression key: rename the UI-written trigger_config.cron_expression to cron, or write the expression under the cron key through the API.
Confirm a worker that consumes the default queue is running, otherwise nothing picks up the dispatched task.

Status and Cancellation

Run statuses include pending, running, waiting, success, failed, cancelled, and timeout; waiting means the run stopped at a Pause node awaiting approval or extra variables. The run drawer can cancel tasks still executing; some external API requests already sent cannot be interrupted. See the Workflow API for streaming run events.

Triggers and Runs

Manual and API Runs

Webhook

Cron

Enabling Cron in a custom deployment

Status and Cancellation

On this page