Appearance
Custom Code
Page Flow Blocks reference.
Blocks
Code Expression
Block name: customcodeexpr
Evaluates a custom JavaScript expression and returns its result. The runtime environment depends on where the block is used: Page Flow expressions run in the browser runtime, while Cloud Flow and AI Agent Flow expressions run in the server-side runtime. Generated expressions must be straightforward and readable: do not minify, obfuscate, use cryptic names, hide intent in clever expressions, or add unnecessary defensive noise. Use documented ioLoop APIs for the current runtime instead of guessing framework internals. If the expression becomes hard to read, use a customcode statement block or Blockly function instead. Use this block for focused computed values, not to hide workflow logic that should be visible as regular flow blocks. The expression can technically access values that are in the surrounding generated flow JavaScript scope through the generated expression wrapper. Only reference names that are intentionally available in the generated flow, such as Blockly variables, same-flow Blockly function/procedure names, documented runtime globals, documented ioLoop APIs, or variables the flow deliberately created for custom expressions to use. Do not depend on incidental temporary variable names or implementation details from Blockly generator routines. If you need the expression to read values that were shared from other custom code blocks, those values can be accessed through $io.system.getFlowShareData.
Inputs
| Input | Type | Description | Accepts |
|---|---|---|---|
| code | code | The JavaScript expression entered in the block's code editor. Keep it readable, direct, and focused on computing a value. Do not use minified, obfuscated, cryptic, overly clever, or noisy defensive code. Use documented ioLoop APIs for the current runtime. You may reference intentionally available names from the surrounding generated flow scope, such as Blockly variables and same-flow Blockly function/procedure names. Do not rely on incidental temporary names from generator routines. Do not use a custom expression to hide workflow logic that should be represented with regular flow blocks. |
Output
This block produces an output value of type Any.
Behavior
At runtime, the generated code evaluates the custom JavaScript expression inside a generated local function in the runtime environment for the current flow type. That generated function is created from the surrounding generated flow JavaScript, so it can access intentionally available names in the surrounding scope, including Blockly variables and same-flow Blockly function/procedure names. Local let, const, and function declarations stay inside that generated function scope. Expressions should use documented ioLoop APIs for the current runtime and remain readable source code, not compact generated output. Do not depend on incidental temporary variable names or implementation details from Blockly generator routines; generator-local names used while producing JavaScript are not runtime variables unless the generated JavaScript explicitly creates a stable value in the same runtime scope. Shared runtime values can be read inside the expression with $io.system.getFlowShareData when needed.
Related Blocks
Custom Code
Block name: customcode
Runs custom JavaScript code inline in the generated flow. The runtime environment depends on where the block is used: Page Flow custom code runs in the browser runtime, while Cloud Flow and AI Agent Flow custom code run in the server-side runtime. Generated code must be straightforward, readable source code: do not minify, compress, obfuscate, use cryptic names, hide intent in clever expressions, or add unnecessary defensive noise. Use meaningful names, normal indentation, line breaks, clear control flow, and short comments for non-obvious logic. Use the documented ioLoop APIs for the current runtime instead of guessing framework internals. Use this block for custom JavaScript that genuinely needs code, not to hide an entire workflow that can be represented clearly with regular flow blocks. The code is placed inside a block and try/catch, so variables declared with let or const are not available outside this custom code block. Custom code can technically access values that are in the surrounding generated flow JavaScript scope. Only reference names that are intentionally available in the generated flow, such as Blockly variables, same-flow Blockly function/procedure names, documented runtime globals, documented ioLoop APIs, or variables the flow deliberately created for custom code to use. Do not depend on incidental temporary variable names or implementation details from Blockly generator routines. If you want to define a function that should be callable from other blocks in the same workspace, using a standard Blockly function block with customcode inside its body is a better approach. Another runtime way to share an object or function with other customcode blocks is to store it with $io.system.setFlowShareData and later read it with $io.system.getFlowShareData.
Inputs
| Input | Type | Description | Accepts |
|---|---|---|---|
| code | code | The JavaScript code entered in the block's code editor. Write readable, maintainable source code with meaningful identifiers, normal formatting, straightforward logic, and comments for non-obvious behavior. Do not use minified, compressed, obfuscated, cryptic, overly clever, or noisy defensive code. Use documented ioLoop APIs for the current runtime. You may reference intentionally available names from the surrounding generated flow scope, such as Blockly variables and same-flow Blockly function/procedure names. Do not rely on incidental temporary names from generator routines. Do not hide an entire workflow inside one large custom code block unless it genuinely cannot be represented clearly with the available flow blocks. |
Output
This block does not produce an output value.
Behavior
At runtime, the generated flow places the custom JavaScript inside a generated block and try/catch in the runtime environment for the current flow type. This does not create a separate function scope, so the code can access intentionally available names in the surrounding generated flow JavaScript scope, including Blockly variables and same-flow Blockly function/procedure names. Block-scoped declarations such as let and const remain local to the generated block. Runtime errors are logged through the flow runtime logger. Custom code should call documented ioLoop APIs for the current runtime and should remain readable source code, not compact generated output. Do not depend on incidental temporary variable names or implementation details from Blockly generator routines; generator-local names used while producing JavaScript are not runtime variables unless the generated JavaScript explicitly creates a stable value in the same runtime scope. For values that need to be shared with other custom code blocks, runtime APIs such as $io.system.setFlowShareData and $io.system.getFlowShareData can be used.
Calls: tvAppInstance.logMsgStr