/workflows-development

name: workflows-development
description: Create and configure Falcon Fusion SOAR workflow YAML for Falcon Foundry apps. TRIGGER when user asks to "create a workflow", "build an automation", "configure Falcon Fusion SOAR", "add an on-demand workflow", runs `foundry workflows create`, or needs help with Falcon Fusion YAML syntax, triggers, actions, or variable references. DO NOT TRIGGER for UI pages, functions, or collection schemas — use the appropriate sub-skill.
version: 1.7.1
updated: 2026-11-10
tags: [foundry, workflows, fusion-soar, yaml]
author: CrowdStrike
license: MIT
compatibility: Claude Code >=1.0
metadata:
  category: automation

Foundry Workflows Development

> Write every workflow definition in Falcon Fusion YAML, validate step dependencies before running it, and handle failures with conditional routing and action-level flags ([Error Handling](#error-handling)) — Fusion has no `onError` blocks and no built-in retry.

> **Part of a suite.** If `development-workflow` has not already run, and this is a new app or its first capability, load the `development-workflow` skill first — it owns the CLI prerequisite check, scaffolding order, and manifest coordination.

Prerequisites

• **Workflow Author role** is required in addition to the Falcon Developer role
• Workflows are YAML templates provisioned as active instances (up to **25** per template)
• **`provision_on_install: true` is REQUIRED** in the workflow YAML — treat it as a per-workflow checklist item, not a footnote. With `true`, installing the app creates the workflow in Falcon Fusion SOAR, turned on. With `false`, the deploy is "Successful" and the template is listed in the app's **Logic** section, but installing creates no workflow, so nothing runs until something provisions it (the `/workflows/system-definitions/provision` API). Use `false` deliberately: for a workflow with an action ID you can't verify, which the user finishes in the console (see [Platform Action Fallback Strategy](references/advanced-patterns.md#platform-action-fallback-strategy)), or to let an app install without the credentials a workflow needs, as the sample apps' e2e tests do.

CLI Scaffolding

# Write the workflow YAML to /tmp/ first — the CLI copies it into workflows/
foundry workflows create --name "my-workflow" --spec /tmp/workflow.yaml --no-prompt
# After: edit workflows/my-workflow.yml to refine workflow logic

Discover Available Actions and Triggers

foundry workflows actions view --name "send email" --no-prompt              # Look up by name
foundry workflows actions view --name "send email" --no-prompt --output-schema  # Output schema
foundry workflows actions view --name "send email" --no-prompt --mock       # Mock output
foundry workflows triggers view --no-prompt                                 # List triggers

> **Always use `--no-prompt` on `actions view`/`triggers view`** — without it, multiple or partial matches trigger an interactive prompt that fails in headless environments (`Error: no TTY available`); as of CLI 2.1.1 matches are listed non-interactively. The bundled `action_search.py` works without a manifest directory — see [references/action-discovery.md](references/action-discovery.md).

Workflow Structure

Trigger + Actions Format (standard)

This is the format produced by `foundry workflows create` and used by many Foundry sample apps — a `trigger:` (with `next:` naming the first action) plus an `actions:` map where each action carries an `id`, `properties`, `version_constraint`, and optional `next:`, closing with `output_fields: []`. See [references/workflow-examples.md](references/workflow-examples.md#standard-trigger-actions-format) for the full canonical YAML (on-demand Okta list → print).

**Trigger types:**

| Type | Format | |------|--------| | On demand | `name: On demand`, `type: On demand` | | Scheduled | `event: Schedule`, `schedule: {time_cycle: "0 */6 * * *", tz: Etc/UTC}` |

**Trigger parameters** (inputs the console prompts for when an on-demand workflow runs) are a JSON Schema object under `trigger:`, read in actions as `${data['name']}`:

trigger:
    name: On demand
    type: On demand
    parameters:
        type: object
        properties:
            recipient:
                type: string
                description: Who gets the report
        required:
            - recipient

> **⚠️ Null-guard trigger parameters:** When run from the Falcon console the UI prompts for parameters, but via API or from another workflow they may be empty. Guard with a `conditions:` branch (`cel_expression: data['param'] != null && data['param'] != ''`, routing to a handler via `else:`) or inline in CEL with a ternary: `${data['param'] != null ? data['param'] : "default"}`. Full `conditions:` block: [references/cel-expressions.md](references/cel-expressions.md#null-guard-trigger-parameters).

**Variable syntax in actions:** Use `${data['action_key.path.to.field']}` CEL expressions. See [Variable References](#variable-references) for the full syntax. Do NOT use `$action_name.output.body` — it passes as a literal string and is not resolved.

**Version constraints:** Set `version_constraint: ~N` on each action, where `N` is the major version of the activity's declared `semantic_version` (not its iteration count): **`~0`** when the activity has no `semantic_version` (functions, API integrations) or a `0.x` one (Contain device is `0.0.x`); **`~1`** for a `1.x` one (Print data, Send email, Create/Update variable, Get device details). Some samples omit it on function actions. Check with `scripts/action_search.py "<action>" --details`, which prints the `semantic_version` and the matching constraint; a worked `~0`/`~1` example is in [references/workflow-examples.md](references/workflow-examples.md#version-constraint-example).

Manifest Configuration

# manifest.yml
workflows:
  - name: my-workflow
    path: workflows/my-workflow.yml
    permissions: []