Stay organized with collections
Save and categorize content based on your preferences.
Expressions are evaluated by the workflow engine and the output is used at the
time of execution, such as assigning the result of an expression to a variable
or returning the result of an expression.
Operate on lists, maps, and strings such as in and keys
Conditionally access data inline such as default and if
Function expressions
Functions such as len() can be used in expressions, and the functions
defined in the standard library
are all supported (with the exception of blocking calls such
as HTTP calls, sys.sleep, and sys.log). For example:
You can extend an expression over multiple lines. For example, you might want to
create a dynamic string for a SQL query. For multi-line expressions, follow
these guidelines:
String literals must be enclosed in double quotes.
You can include colons within a string literal.
Any required whitespace must be added inside the string literal.
For example, to generate "SELECT * from customers\nWHERE id=7", create a step
like this:
Calls performed during a workflow can be either blocking or non-blocking.
Blocking calls are calls that block a workflow's execution; they must be
resolved before a workflow execution can complete.
Certain functions result in blocking calls if used inside an expression. Instead,
they must be run from a call step (see Calls).
For example,sys.sleep and http.get cannot be used inside an expression.
The following list contains all the functions that result in blocking calls in
Workflows:
[[["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-25 UTC."],[],[],null,["# Expressions are evaluated by the workflow engine and the output is used at the\ntime of execution, such as assigning the result of an expression to a variable\nor returning the result of an expression.\n\nThere is a limit to the [expression length](/workflows/quotas#resource_limits).\n\nAll expressions must begin with a `$` and be enclosed in curly brackets: \n\n```yaml\n ${\u003cvar translate=\"no\"\u003eEXPRESSION\u003c/var\u003e}\n```\n\nYou can use expressions to:\n\n- [Assign values to variables](/workflows/docs/reference/syntax/variables#assign-step)\n- [Form call arguments](/workflows/docs/reference/syntax/calls), including all parameters in the `body`, `header`, `query`, and `url` sections\n- [Call subworkflows](/workflows/docs/reference/syntax/subworkflows#call-subworkflow-expression)\n- [Apply conditions](/workflows/docs/reference/syntax/jumps#conditional-jumps)\n- [Retry values](/workflows/docs/reference/syntax/retrying), including `max_retries` and `multiplier`\n- [Return values](/workflows/docs/reference/syntax/completing#using-return) from a workflow step\n\n| **Important:** In YAML, expressions containing colons can cause unexpected behaviour when the colon is interpreted as defining a map. You can resolve this issue by wrapping the YAML expression in single quotes:\n|\n| Recommended: `'${\"foo: \" + myVar}'`\n|\n| Not recommended: `${\"foo: \" + myVar}`\n| For details, see [Expressions containing colons](/workflows/docs/troubleshooting#expressions-colons).\n\nSupported elements\n------------------\n\nThe Workflows syntax supports the following elements in the\ndefinition of an expression:\n\n- `[0...9]`: numbers\n- `\"\"`: strings\n- `-` (minus sign): indicates negative numbers\n- `.` (dot): indicates decimal place\n- `+`: arithmetic addition and string concatenation\n- `-`: arithmetic subtraction and negation\n- `*`: arithmetic multiplication\n- `/`: float division\n- `%`: remainder division\n- `//`: floor division\n- `()`: parentheses\n- [Logical operators](/workflows/docs/reference/syntax/datatypes#logical-operators)\n- `variableName`: reference a variable\n- `object.field`: reference a value in an object\n- `object[\"field\"]`: reference a value in an object\n- `list[index]`: reference an index in a list\n- [Expression helpers](/workflows/docs/reference/stdlib/expression-helpers) that can:\n - Convert data such as `int` and `string`\n - Operate on lists, maps, and strings such as `in` and `keys`\n - Conditionally access data inline such as `default` and `if`\n\nFunction expressions\n--------------------\n\nFunctions such as `len()` can be used in expressions, and the functions\ndefined in the [standard library](/workflows/docs/reference/stdlib/overview)\nare all supported (with the exception of [blocking calls](#blocking-calls) such\nas HTTP calls, `sys.sleep`, and `sys.log`). For example: \n\n### YAML\n\n```yaml\n - initVariables:\n assign:\n - project: ${sys.get_env(\"GOOGLE_CLOUD_PROJECT_ID\")}\n \n```\n\n### JSON\n\n```json\n [\n {\n \"initVariables\": {\n \"assign\": [\n {\n \"project\": \"${sys.get_env(\\\\\"GOOGLE_CLOUD_PROJECT_ID\\\\\")}\"\n }\n ]\n }\n }\n ]\n \n```\n\nMulti-line expressions\n----------------------\n\nYou can extend an expression over multiple lines. For example, you might want to\ncreate a dynamic string for a SQL query. For multi-line expressions, follow\nthese guidelines:\n\n- String literals must be enclosed in double quotes.\n- You can include colons within a string literal.\n- Any required whitespace must be added inside the string literal.\n\nFor example, to generate `\"SELECT * from customers\\nWHERE id=7\"`, create a step\nlike this: \n\n### YAML\n\n```yaml\n - assign:\n assign:\n - table: customers\n - id: 7\n - q: ${\n \"SELECT * from \" + table +\n \"\\nWHERE id=\" + string(id)\n }\n```\n\n### JSON\n\n```json\n [\n {\n \"assign\": {\n \"assign\": [\n {\n \"table\": \"customers\"\n },\n {\n \"id\": 7\n },\n {\n \"q\": \"${\\n\\\"SELECT * from \\\" + table +\\n\\\"\\\\nWHERE id=\\\" + string(id)\\n}\"\n }\n ]\n }\n }\n ]\n```\n\nBlocking calls\n--------------\n\nCalls performed during a workflow can be either *blocking* or *non-blocking* .\n*Blocking calls* are calls that block a workflow's execution; they must be\nresolved before a workflow execution can complete.\n\nCertain functions result in blocking calls if used inside an expression. Instead,\nthey must be run from a `call` step (see [Calls](/workflows/docs/reference/syntax/calls)).\nFor example,`sys.sleep` and `http.get` cannot be used inside an expression.\n\nThe following list contains all the functions that result in blocking calls in\nWorkflows:\n\n- `events.await_callback` ([events.await_callback function](/workflows/docs/reference/stdlib/events/await_callback))\n- `experimental.executions.map` ([executions.map function](/workflows/docs/reference/stdlib/experimental.executions/map))\n- `experimental.executions.run` ([executions.run function](/workflows/docs/reference/stdlib/experimental.executions/run))\n- `googleapis.*` ([for connector calls](/workflows/docs/reference/stdlib/googleapis/overview))\n- `http.*` ([HTTP functions](/workflows/docs/reference/stdlib/overview#module:-http))\n- `sys.log` (see [Send logs to Cloud Logging](/workflows/docs/log-workflow#use-sys-log))\n- `sys.sleep` (see [Wait using polling](/workflows/docs/sleeping))"]]