Stay organized with collections
Save and categorize content based on your preferences.
To create a workflow, you define the steps you want and their order of execution
using the Workflows syntax. Every workflow must have at least one step.
By default, Workflows treats steps as if they are in an ordered
list and executes them one at a time until all the steps have run. For example,
this workflow has two steps:
Step names must be unique at the
subworkflow level. For example,
in the following workflow, a step named init is allowed in both the main
block and the subworkflow.
Workflows doesn't enforce a naming convention for step names.
However, we recommend consistent usage such as creating step names that only
include alphanumeric characters and underscores.
Step types
Workflows supports various types of steps, including the following:
This sample shows implicit step ordering within a workflow. By default, the
steps of a workflow are executed in the order they appear in the workflow
definition.
Variables declared in a steps block have workflow-level scope and can be
accessed outside of the block. Any step type can be nested inside of a steps
block including assign, call, and switch. For example:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[],[],null,["# Steps\n\nTo create a workflow, you define the steps you want and their order of execution\nusing the Workflows syntax. Every workflow must have at least one step.\n\nBy default, Workflows treats steps as if they are in an ordered\nlist and executes them one at a time until all the steps have run. For example,\nthis workflow has two steps: \n\n### YAML\n\n```yaml\n - STEP_NAME_A:\n ...\n - STEP_NAME_B:\n ...\n \n```\n\n### JSON\n\n```json\n [\n {\n \"\u003cvar translate=\"no\"\u003eSTEP_NAME_A\u003c/var\u003e\": {\n ...\n }\n },\n {\n \"\u003cvar translate=\"no\"\u003eSTEP_NAME_B\u003c/var\u003e\": {\n ...\n }\n },\n ]\n \n```\n\nStep names\n----------\n\nStep names must be unique at the\n[subworkflow](/workflows/docs/reference/syntax/subworkflows) level. For example,\nin the following workflow, a step named `init` is allowed in both the `main`\nblock and the subworkflow. \n\n### YAML\n\n```yaml\nmain:\n params: [input]\n steps:\n - init:\n call: sub\nsub:\n steps:\n - init:\n assign:\n - a: 0\n```\n\n### JSON\n\n```json\n{\n \"main\": {\n \"params\": [\n \"input\"\n ],\n \"steps\": [\n {\n \"init\": {\n \"call\": \"sub\"\n }\n }\n ]\n },\n \"sub\": {\n \"steps\": [\n {\n \"init\": {\n \"assign\": [\n {\n \"a\": 0\n }\n ]\n }\n }\n ]\n }\n}\n```\n\nWorkflows doesn't enforce a naming convention for step names.\nHowever, we recommend consistent usage such as creating step names that only\ninclude alphanumeric characters and underscores.\n\nStep types\n----------\n\nWorkflows supports various types of steps, including the following:\n\n- [Assign a variable](/workflows/docs/reference/syntax/variables)\n- [Apply conditions](/workflows/docs/reference/syntax/conditions)\n- [Invoke an HTTP endpoint](/workflows/docs/http-requests)\n- [Execute workflow steps in parallel](/workflows/docs/execute-parallel-steps)\n- [Return a value](/workflows/docs/reference/syntax/calls)\n- [Pause a workflow](/workflows/docs/sleeping)\n\nImplicit step ordering\n----------------------\n\nThis sample shows implicit step ordering within a workflow. By default, the\nsteps of a workflow are executed in the order they appear in the workflow\ndefinition.\n\n### YAML\n\n - first_step:\n call: http.get\n args:\n url: https://www.example.com/callA\n - second_step:\n call: http.get\n args:\n url: https://www.example.com/callB\n - third_step:\n call: http.get\n args:\n url: https://www.example.com/callC\n\n### JSON\n\n [\n {\n \"first_step\": {\n \"call\": \"http.get\",\n \"args\": {\n \"url\": \"https://www.example.com/callA\"\n }\n }\n },\n {\n \"second_step\": {\n \"call\": \"http.get\",\n \"args\": {\n \"url\": \"https://www.example.com/callB\"\n }\n }\n },\n {\n \"third_step\": {\n \"call\": \"http.get\",\n \"args\": {\n \"url\": \"https://www.example.com/callC\"\n }\n }\n }\n ]\n\nNested steps\n------------\n\nYou can use a `steps` block to nest a series of steps and further define a\nworkflow: \n\n### YAML\n\n```yaml\n - STEP_NAME:\n steps:\n - STEP_NAME_1:\n steps:\n - STEP_NAME_A:\n ...\n - STEP_NAME_B:\n ...\n - STEP_NAME_2:\n steps:\n - STEP_NAME_C:\n ...\n \n```\n\n### JSON\n\n```json\n {\n STEP_NAME: {\n \"steps\": [\n {\n STEP_NAME_1: {\n \"steps\": [\n {\n STEP_NAME_A:\n ...\n },\n {\n STEP_NAME_B:\n ...\n }\n ]\n }\n },\n {\n STEP_NAME_2: {\n \"steps\": [\n {\n STEP_NAME_C:\n ...\n }\n ]\n }\n }\n ]\n }\n }\n \n```\n\nVariables declared in a `steps` block have workflow-level scope and can be\naccessed outside of the block. Any step type can be nested inside of a `steps`\nblock including `assign`, `call`, and `switch`. For example: \n\n### YAML\n\n```yaml\n main:\n steps:\n - series_one:\n steps:\n - step_a:\n call: http.get\n args:\n url: https://host.com/api1\n result: api_response1\n - step_b:\n assign:\n - varA: \"Monday\"\n - varB: \"Tuesday\"\n - series_two:\n steps:\n - step_c:\n call: http.get\n args:\n url: https://host.com/api2\n result: api_response2\n - step_d:\n assign:\n - varC: \"Wednesday\"\n - varD: \"Thursday\"\n \n```\n\n### JSON\n\n```json\n {\n \"main\": {\n \"steps\": [\n {\n \"series_one\": {\n \"steps\": [\n {\n \"step_a\": {\n \"call\": \"http.get\",\n \"args\": {\n \"url\": \"https://host.com/api1\"\n },\n \"result\": \"api_response1\"\n }\n },\n {\n \"step_b\": {\n \"assign\": [\n {\n \"varA\": \"Monday\"\n },\n {\n \"varB\": \"Tuesday\"\n }\n ]\n }\n }\n ]\n }\n },\n {\n \"series_two\": {\n \"steps\": [\n {\n \"step_c\": {\n \"call\": \"http.get\",\n \"args\": {\n \"url\": \"https://host.com/api2\"\n },\n \"result\": \"api_response2\"\n }\n },\n {\n \"step_d\": {\n \"assign\": [\n {\n \"varC\": \"Wednesday\"\n },\n {\n \"varD\": \"Thursday\"\n }\n ]\n }\n }\n ]\n }\n }\n ]\n }\n }\n \n```\n\nNote that in some cases, `steps` is required; for example, when defining a\n[subworkflow](/workflows/docs/reference/syntax/subworkflows) or a [for loop](/workflows/docs/reference/syntax/iteration)."]]