Workflows
Commands for managing workflows in the Knock CLI.
Workflow commands enable you to manage workflows in your Knock account from the CLI.
Workflow file structure
#When workflows are pulled from Knock, they are stored in directories named by their workflow key. In addition to a workflow.json file that describes all of a given workflow's steps, each workflow directory also contains individual folders for each of the channel steps in the workflow that hold additional content and formatting data.
workflows/ └── my-workflow/ ├── email_1/ │ ├── visual_blocks/ │ │ └── 1.content.md │ └── visual_blocks.json ├── in_app_feed_1/ │ └── markdown_body.md └── workflow.json
If you're migrating your local workflow files into Knock, you can arrange them using the example file structure above and then push them into Knock with a single command using knock workflow push --all. Each workflow.json file should follow the structure defined here.
knock workflow list [flags]
#You can see all your existing workflows in a given environment with the workflow list command.
Use an --environment flag to specify the target environment; if omitted, the Knock CLI defaults to the development environment.
Flags
The environment to use. Defaults to development.
Should any uncommitted changes be hidden? Defaults to false.
The total number to fetch per page.
Fetches all entries after this cursor.
Fetches all entries before this cursor.
Format output as json.
knock workflow get [flags]
#You can show more details about a given workflow with the workflow get command, followed by the target workflow key.
Use an --environment flag to specify the target environment; if omitted, the Knock CLI defaults to the development environment.
Flags
The environment to use. Defaults to development.
Should any uncommitted changes be hidden? Defaults to false.
Format output as json.
knock workflow new [flags]
#Create a new workflow with a minimal configuration. You can either select steps interactively or use a template to scaffold the workflow.
The command will create a new workflow directory in your local file system. By default, this will be in the workflows resource directory set by your knock.json file, or the current working directory if not configured.
Flags
The key for the workflow. If not provided, will be prompted or inferred from the workflow directory name.
The name for the workflow. If not provided, will be generated from the key.
The environment to use. Defaults to development.
The branch to use. Defaults to the main branch.
A comma-separated list of step types to include in the workflow (e.g., 'email,sms,in_app_feed'). If not provided, you will be prompted to select steps interactively.
A template to use for scaffolding the workflow. Can be a GitHub repository path (e.g., 'workflows/digest-email').
Push the workflow to Knock after creating it locally. Defaults to false.
Overwrites an existing workflow directory without prompting for confirmation. Defaults to false.
knock workflow pull [flags]
#You can pull and download workflows with its message templates from Knock to a local file system with the workflow pull command. Knock CLI will create a new workflow directory or update the existing workflow directory in the local file system.
By default this command will resolve to the workflows resource directory via your knock.json file. When not set, will use the current working directory as the default. In the case of the --all flag, the target directory path will be resolved via your knock.json file or the --workflows-dir flag.
Note: if pulling the target workflow for the first time (or all workflows), Knock CLI will ask to confirm before writing to the local file system.
See the Workflow file structure section for details on how workflow files are organized.
Flags
The environment to use. Defaults to development.
Whether to pull all workflows from the specified environment into the target directory path set by --workflows-dir. Defaults to false.
When used, all contents in the target directory will be erased and replaced with all workflows from the specified environment.
Specifies which target directory path to pull all workflows into. Only available to be used with --all, and defaults to the current working directory.
Should any uncommitted changes be hidden? Defaults to false.
Removes the confirmation prompt. Defaults to false.
knock workflow push [flags]
#You can push and upload a workflow directory to Knock with the workflow push command. Knock will update an existing workflow by the matching workflow key, or create a new workflow if it does not exist yet.
By default this command will resolve to the workflows resource directory via your knock.json file. When not set, will use the current working directory as the default. In the case of the --all flag, the target directory path will be resolved via your knock.json file or the --workflows-dir flag.
Note:
- The
workflow pushcommand only pushes workflows into thedevelopmentenvironment. - You must be directly above the target workflow directory when running the
workflow pushcommand, so the CLI can locate theworkflow.jsonfile. - You can also pass in the
--commitflag (with an optional--commit-messageflag) to commit the upserted changes immediately.
See the Workflow file structure section for details on how workflow files are organized.
Flags
Push and commit the workflow(s) at the same time. Defaults to false.
The commit message to pass when using the --commit flag.
Whether to push all workflows from the target directory path set by --workflows-dir. Defaults to false.
Specifies the target directory path to find and push all workflows from. Only available to be used with --all, and defaults to the current working directory.
knock workflow run <workflow_key> [flags]
#You can run a workflow with the workflow run command. Knock will execute a run for the latest saved version of the workflow it finds with the given key and parameters you send it.
Note:
- Changes to the local version of the workflow in your file system will not be reflected in a workflow run; it will use the current version that is stored in Knock.
Flags
The slug of the environment in which to run this workflow. Defaults to development.
One or more recipient ids for this workflow run, maximum limit 5.
A JSON string of the data with which this workflow will run.
An optional actor id for this workflow run.
An optional tenant id for this workflow run.
knock workflow validate <workflow_key> [flags]
#You can validate a new or updated workflow directory with the workflow validate command. Knock will validate the given workflow payload in the same way as it would with the workflow push command, except without persisting those changes.
Note: Validating a workflow is only done against the development environment.
Flags
Whether to validate all workflows from the target directory path set by --workflows-dir. Defaults to false.
Specifies the target directory path to find and validate all workflows from. Only available to be used with --all, and defaults to the current working directory.
knock workflow activate [flags]
#You can activate or deactivate a workflow in a given environment with the workflow activate command.
Note:
- This immediately enables or disables a workflow in a given environment without needing to go through environment promotion.
- By default, this command activates a given workflow. Pass in the
--statusflag withfalsein order to deactivate it.
Flags
The environment to activate the workflow in.
Removes the confirmation prompt. Defaults to false.
The status to set. Defaults to true.
knock workflow generate-types [flags]
#Generate type definitions for workflow trigger data from your workflow schemas. This command fetches workflows with trigger data schemas and generates type-safe definitions for TypeScript, Python, Ruby, and Go.
The generated types enable compile-time safety when triggering workflows in your application code, helping catch integration errors before runtime. The target language is inferred from the output file extension.
Learn more about type safety with workflows.
Flags
The environment to fetch workflows from. Defaults to development.
Specifies the file to generate types into. The language is inferred from the file suffix.