Workflows

Cloud-native workflows are the execution unit in Alteryx One. They are keyed by ULIDs and served by the /svc-workflow/api/vN service.

The on-prem Designer/Server workflow surface is separate and is not interchangeable:

• ayx designer workflow operates on on-prem Designer/Server packages (.yxmd, .yxzp) — a different technology entirely, reached by migration rather than configuration. See Workflows & packages.

The workflows surface is for inspecting, running, and managing existing canvas workflows. Authoring arbitrary visual workflow logic is out of scope: no public endpoint accepts it.

Mutating commands are dry-run by default — add --apply to commit.

Quick reference

Command	Key options	What it does
ayx one workflows list	--profile, --env, --limit, --page-token, --all, --max-pages	List cloud-native workflows
ayx one workflows count	--profile, --env	Return the workspace workflow count
ayx one workflows detail <id>	--profile, --env, --include-dependencies	Inspect one ULID-keyed workflow — see Inspect
ayx one workflows graph <id>	--profile, --env	Inspect provider-supplied nodes, configurations, ports, and connections — see Inspect
ayx one workflows dependencies <id>	--profile, --env	List its connections, datasets, and macros — see Inspect
ayx one workflows engines <id>	--profile, --env	Show available execution engines — see Inspect
ayx one workflows tools	--env	List tools available to cloud-native workflows — see Inspect
ayx one workflows assets	--profile, --env, --limit, --page-token, --all, --max-pages	List the richer workflow-asset projection — see Inspect
ayx one workflows run <id>	--profile, --env, --body	Queue a workflow run; returns jobId and jobgroupId
ayx one workflows cancel <job-id>	--profile, --env	Cancel a queued or running run using its returned jobId
ayx one workflows copy <id>	--profile, --env, --name, --version	Duplicate a workflow — see Copy & share
ayx one workflows share <id>	--profile, --env, --to-person, --to-group, --privilege, --include-dependencies, --send-email, --message, --body, --no-resolve-emails	Share a workflow with people or groups — see Copy & share
ayx one workflows delete <id>	--profile, --env	Permanently delete a workflow — see Delete

Every leaf also accepts the global --output, --apply, --verbose, --debug, --no-verify-tls, and --yes flags. Use -o json for automation, --env <ENVIRONMENT_FLAG> to select a named environment, and --profile <name> on the leaves that expose it.

List and count

List workflows

# Use the server's default page size
ayx one workflows list

# Set an explicit limit or start from a returned page token
ayx one workflows list --limit 100
ayx one workflows list --page-token <token>

# Request the all-items form and inspect data.complete in the envelope
ayx -o json one workflows list --all

The list response uses data.items. The current /v4/workflows endpoint reports a collection count but does not provide reliable cursor pagination; data.complete tells you whether the fetched item count reached that total. If it is false, increase --limit and check again.

Count workflows

ayx one workflows count
ayx one workflows count --profile <name>
ayx -o json one workflows count

count is synthesized client-side from the workflow-list response because the API has no /v4/workflows/count route. Its output includes count_source, so consumers can distinguish this assembly from a server-side count lookup.

Inspect a workflow graph

ayx -o json one workflows graph <workflow-ulid>

The command preserves the provider response under data.response and adds a normalized data.graph with nodes, configurations, ports, and connections buckets. A schema is included only when the provider supplied one; the CLI does not infer field-level schemas.

Automation patterns

# Extract every workflow id and name as TSV
ayx -o json one workflows list --all \
  | jq -r '.data.items[] | [.id, .name] | @tsv'

# Verify a --all fetch actually reached the reported total
ayx -o json one workflows list --all | jq '.data.complete'

# Compare the synthesized count against the number of items returned
ayx -o json one workflows count | jq '{count: .data.count, source: .data.count_source}'

Run and cancel

Run a saved cloud-native workflow by its workflow ULID. The first command is a dry-run; add --apply only when you are ready to queue the job:

ayx -o json one workflows run <workflow-ulid>
ayx -o json one workflows run <workflow-ulid> --apply --yes

The applied response contains both a provider jobId and jobgroupId. Use the jobId to cancel the execution:

ayx -o json one workflows cancel <job-id>
ayx -o json one workflows cancel <job-id> --apply --yes

To inspect the child runs for that workflow execution, pass the returned jobgroupId to the canonical Job Library command:

ayx -o json one jobs runs <jobgroup-id>

There is no separate one workflows runs command: the provider exposes run history through the Job Group child collection. cancel takes jobId, not the workflow definition ULID or jobgroupId; pass jobgroupId to one jobs runs. Both workflow controls use /svc-workflow/api/v1; run history uses /v4/jobGroups/{id}/jobs. If the workflow accepts runtime overrides or input parameters, pass the documented JSON body with --body <FILE|JSON|-> on run; prefer a file or piped stdin for sensitive values because inline JSON is visible in shell history and process listings.

Honesty notes

• count is a client-side synthesis, not a real server route. Its envelope includes count_source. The same applies to detail — see Inspect.
• one workflows runs is intentionally not exposed. The provider’s Job Group child collection is the run-history boundary: use one jobs runs <jobgroupId> for the jobgroupId returned by one workflows run.
• This command family runs and manages existing cloud-native workflows; it does not author arbitrary canvas logic because no endpoint accepts it.

Known limitations

• --output table is currently an alias for --output text, not a distinct table renderer. It goes through the same text-mode rendering path.
• list --all currently returns a data.complete boolean rather than guaranteeing that every item was fetched through cursor pagination. The /v4/workflows endpoint is limit-based and does not expose reliable cursor pagination; if complete is false, use an explicit --limit above your expected total and verify it becomes true.

Related

• Inspect — detail, dependencies, engines, tools, and assets
• Run and cancel — queue a workflow and stop its run safely
• Copy & share — duplicate a workflow or grant access
• Delete — permanently remove a workflow; no restore endpoint exists
• Datasets — the One dataset library
• Plans — orchestrate multi-flow plans
• Safety model — dry-run and --apply in detail
• Output & automation — structured envelopes and JSON pipelines