Version: v5.6.1

opschain scheduled-activities create

Included from Basic tier

opschain scheduled-activities create <project> -f <file.yaml> [-i key=value ...]

Schedules a workflow on the project (POST /api/scheduled_activities) from a flat YAML definition whose keys mirror the API's writable scheduled-workflow attributes verbatim — the file is the write payload. The accepted keys, exactly:

workflow_code, cron_schedule, run_at, repeat, maximum_run_count, end_at, allow_parallel_execution, auto_continue_wait_steps, enabled, version, metadata, property_overrides, notify, inputs

The file is loaded strictly: an unknown key fails naming the accepted set rather than being silently dropped, and workflow_code — the workflow the schedule runs — is the one key the CLI itself requires. Everything else is validated by the create endpoint, the same validation a GUI edit runs:

the schedule shape pairs repeat: true with cron_schedule (the cron decides when it runs), and a one-shot sets run_at instead — supplying both cron_schedule and run_at is refused by the CLI itself before anything is sent (exit 2), and supplying the wrong half of either pair is a named 422;
a pinned version resolves at schedule time, and the typed inputs object is dry-run against that version's declarations exactly as run creation would validate them — unknown names, type/enum mismatches and unsatisfied required inputs are named 422s before anything is stored;
an unpinned schedule (no version, or latest) resolves latest-at-firing, so the static dry run is skipped and every firing re-validates instead.

-i/--input overlays the file's inputs object per key (repeatable; a repeated key builds a list), exactly like runs create's -i. A secret-typed input accepts vault references only and is served masked (******) on every read of the schedule and of the runs it fires.

Scheduled changes cannot be created — scheduled-change writes are not implemented, and their marker attributes (action, settings_overrides) are outside the accepted key set.

On success: created scheduled activity <id> (workflow <code>, next run <timestamp>) (-o json|yaml prints the created resource instead). The id is how update, delete and show address the schedule. Needs a server target (--server <url>, OPSCHAIN_SERVER, or the active context).

Flags

Flag	Meaning
`-f, --file <file>`	The YAML scheduled-activity definition (required).
`-i, --input <key=value>`	Typed input overlaying the file's `inputs` object (repeatable; a repeated key builds a list).

Exit codes

Code	Meaning
0	Scheduled activity created.
1	The command failed (server-side validation refused the definition).
2	Usage error — missing `-f`, unreadable/invalid file, missing `workflow_code`, no server target.

Named errors

<file> must set workflow_code (the workflow the schedule runs) — exit 2.
<file>: unknown scheduled activity attribute(s) <keys> (accepted: workflow_code, cron_schedule, run_at, repeat, maximum_run_count, end_at, allow_parallel_execution, auto_continue_wait_steps, enabled, version, metadata, property_overrides, notify, inputs) — exit 2.
run_at cannot be set on a repeating schedule (cron_schedule is set) — supply one or the other — both schedule halves in one definition, exit 2.
input <name> is required and was not supplied — the pinned-version schedule-time dry run, exit 1.

Example

# nightly-patch.yaml
workflow_code: patch-infrastructure
cron_schedule: "0 2 * * 6"
repeat: true
version: 3
inputs:
  environments: [dev, test]
  unattended: true

opschain scheduled-activities create demoenterprise -f nightly-patch.yaml -i unattended=false
created scheduled activity 01a13c58-… (workflow patch-infrastructure, next run 2026-10-17T02:00:00.000000Z)

Flags​

Exit codes​

Named errors​

Example​

See also​

Flags

Exit codes

Named errors

Example

See also