Scheduled Tasks

Scheduled tasks trigger a deployed workflow on a recurring cron schedule, with no manual intervention.

Creating a schedule

Attach a schedule to a workflow from the Scheduled Tasks view. Choose the workflow the task will run — this is the first field, and it is required, because the chosen workflow is the task's entire behavior. Then pick a frequency preset — minutes, hourly, daily, weekly, monthly — or write a custom cron expression, and choose a timezone. A live preview validates the expression and shows the next run time.

The task's title and notes are labels for people. Neither is read when the task runs, so a task named "daily report" only produces a report if the workflow you selected does.

Each schedule carries a cron expression, an IANA timezone, an optional start time, and a lifecycle of recurring or one-shot (limited, with a maxRuns cap).

Managing schedules

Schedules can be paused and resumed with an enabled flag (no need to delete), edited, run immediately with Run now, or deleted. Manage them in the app or through the Schedules API.

How schedules run

Due schedules are dispatched by the scheduler worker, which polls on an interval (default 60s), enqueues runs for due schedules, and also sweeps durable timer waits. Runs then execute through the workflow queue — via Redis/BullMQ when REDIS_URL is set, or inline otherwise.

The Command Center's scheduled commands run on the same due-processing machinery.

Mechanical schedule vs. adaptive job

Every recurring automation has one explicit execution mode, and the two modes are mutually exclusive:

• workflow (mechanical, the default): the schedule drives a native scheduleTrigger on a deployed workflow. Each recurrence traverses the pinned graph deterministically, like n8n — it does not ask a model to re-plan. This is what a scheduled task creates.
• adaptive-job: the schedule re-plans a Command Center prompt on every recurrence via a Command job. Use this only when you want the plan itself to change each run.

One request can never create both a native schedule trigger and an adaptive Command schedule for the same recurrence — that dual-mode configuration is rejected at validation, so a single intent always produces exactly one schedule path and one run per tick (no duplicate runs or side effects). Deploying the same workflow twice does not create a second native schedule.

Human approvals in scheduled runs

Scheduled workflows can include Human in the Loop approval blocks. When a scheduled run reaches an approval block, the run moves to waiting and stays durably parked until an authorized user approves, rejects, or the approval expires.

Approval blocks can collect typed form fields with the decision:

Fields can be required, and invalid submissions return field-level errors. The approval response is included in the node output under form, alongside the decision and optional comment.

Confluye supports more than one active approval wait in a run, including approvals created by parallel branches. Each approval is keyed by its wait token, and deciding one approval does not consume sibling waits. Concurrent attempts to decide the same approval are single-use; the loser receives 410.

Next steps