Cloud Flow Editor

The Cloud Flow Editor is the visual programming canvas for creating and maintaining server-side logic in an ioLoop Project. It is used to edit the logic of Background Tasks, Web Hooks, and supported AI Agent-related Cloud Flow modules.

Like the Page Flow Editor, it lets you select blocks from a toolbox, connect them, configure their values, and combine visual programming with JavaScript. The important difference is the execution environment: Page Flow runs in the browser, while Cloud Flow runs on the server and can use the ioLoop Server API and supported backend capabilities.

This guide covers editing Cloud Flow logic. For creating modules, changing Web Hook settings, enabling or disabling modules, or configuring load order, see Managing Cloud Flow. For exact block inputs and behavior, see the Cloud Flow Blocks reference.

Opening the Cloud Flow Editor

To open an existing module:

1. Open Backend → Cloud Flow in the Project Editor.
2. Select the Background Task or Web Hook to edit.
3. Choose Edit Flow.
4. Build or modify the blocks on the canvas.
5. Choose Save to retain the changes.

Each module has its own logic. Editing one Web Hook or Background Task does not automatically change other modules, although those modules may use the same Database tables, Connections, and Flow Share helpers.

If you need a new module, create it from the Cloud Flow list first. Background Tasks have no separate trigger or scheduling configuration: their behavior, including any timer-based activity, is implemented in the module's own logic. Web Hooks have settings for request-based invocation.

Understanding the Editor

The editor provides three main areas:

Area	Purpose
Toolbox	Contains available Cloud Flow blocks grouped by purpose, with Search for locating blocks.
Canvas	Holds the blocks and the logic you assemble for the selected module.
Canvas controls	Provide navigation such as zoom, pan, and search within a larger flow.

A module can contain multiple groups of blocks—for example, initialization, validation, Database access, shared functions, and response handling. Arrange related logic together so other Creators can understand what the module does.

Statement Blocks and Value Blocks

Blocks connect differently according to their roles.

Block Role	Purpose
Statement blocks	Perform operations and can form sequences or branches.
Value blocks	Produce values for inputs on other blocks.
Logic and control blocks	Express conditions, repetition, and other control structures.
Functions and procedures	Organize logic for reuse within a module.

For example, a conceptual Web Hook flow might look like:

Read request
  Validate required values
  Check authorization
  Perform permitted operation
  Build result
  Set response

This illustrates the responsibilities and order; these lines are not specific block names.

Flow Start and Execution

The Flow Start block is an optional organizational marker. It generates no runtime operation of its own, and blocks do not have to be connected beneath it in order to run.

Actual execution depends on how the generated code is arranged and on the module's runtime behavior:

• A Background Task can initialize its own processing, timers, or shared helpers through its logic. It is not started by an external scheduling setting.
• A Web Hook handles request-based behavior using the appropriate Cloud Flow blocks and response handling.
• AI Agent-related modules run within their supported agent context.
• Functions and event-related logic execute when called or invoked through the mechanism they define.

Do not infer that a block executes merely because it is visible on the canvas, or that every block outside Flow Start is inactive. Follow the documented behavior of the particular block and module.

For details about module types, see Cloud Flow Types.

Connecting and Ordering Blocks

A typical editing sequence is:

1. Identify the operation or value you need.
2. Find the corresponding block in the toolbox.
3. Drag it onto the canvas.
4. Connect it to the appropriate sequence, control structure, procedure, or value input.
5. Configure fields, expressions, table names, query inputs, or other references.
6. Add any result-handling and error paths the operation requires.
7. Review the logic and save.

A value block must be connected to an appropriate accepting input. A statement's relationship to surrounding blocks affects execution order and conditional behavior.

Asynchronous operations need explicit attention. Database operations, file processing, HTTP calls, Connections, and SDK methods may not complete immediately. Use their supported completion or result paths, or await in JavaScript where appropriate, before acting on their results. Do not infer completion solely from visual placement.

Navigating the Canvas

Cloud Flow modules can become large. Use the editor's navigation tools to stay oriented.

Control	Use
Zoom	Inspect individual settings or see more blocks at once.
Pan	Move between areas of the canvas.
Toolbox Search	Find a block that can be added.
Canvas Search	Find content already present on the canvas.

Toolbox Search and Canvas Search are different. Searching for an available Database block is different from locating a Database block already placed in the current Cloud Flow.

Group related blocks near each other, use meaningful procedure names, and comment on rules whose purpose is not obvious.

Choosing Blocks from the Toolbox

The toolbox provides backend block families. The exact categories and available blocks depend on the selected module and editor context.

Block Family	Typical Use
Flow	Organize logic and runtime behavior.
Web Hook / HTTP	Work with requests, response values, status codes, headers, and HTTP operations.
Database	Read, query, create, update, or delete Project records.
Files	Process files, content, streams, and generated file output.
Connections	Use configured external service connections.
Result Objects	Construct and inspect structured results.
Flow Share	Expose or retrieve runtime values and helper functions across supported backend modules.
AI Agents	Implement supported agent-related operations, where available.
Logic, Text, Lists, Math, and Objects	Build conditions and transform values.
Functions and Variables	Organize logic and reuse values inside the module.
Advanced	Use additional supported programming constructs, including custom code.

Start with the intended operation, not the block name. For example, if a Web Hook should validate a registration request, retrieve an event, and return a result, look for request-handling, Database, logic, and response blocks before reaching for JavaScript.

The generated Cloud Flow Blocks reference documents precise inputs, outputs, and behavior. Toolbox group names and reference navigation may not always match exactly.

Using Block Help

Many ioLoop blocks include documentation links.

1. Right-click the block on the canvas.
2. Choose Help, if the action is available.
3. Review the block's inputs, outputs, execution behavior, and related references.
4. Return to the editor and configure the block.

If Help is not available on a particular block, use the Cloud Flow Blocks reference or search the documentation.

Block Right-Click Menu

Right-clicking an individual block opens its contextual actions. Options vary by block and state.

Action	Purpose
Clipboard Export	Copy compatible block structure to the clipboard for reuse.
Duplicate	Create a copy of the selected block and attached children.
Add Comment	Attach an explanatory note.
Inline Inputs	Switch the visual arrangement of supported inputs.
Collapse Block	Hide the block's internal detail to simplify the canvas view.
Disable Block	Retain a block while excluding its generated behavior.
Delete Block	Remove a block from the canvas.
Help	Open the block's documentation when available.

The menu reflects the block's current state. For example, an expanded block can offer Collapse Block, and a disabled block can offer an action to enable it again.

Duplicate

Use Duplicate for similar logic that needs a different configuration. After duplicating, check retained references such as table names, query identifiers, Connection names, and Flow Share keys. A copied operation may still refer to the original resources.

Comments

Use Add Comment to record why logic exists: a business rule, an expected caller, a required load-order dependency, or a reason for handling an error in a particular way. Prefer useful context rather than repeating the block's visible description.

Inline Inputs and Collapse Block

Inline Inputs changes the appearance of compatible inputs. Collapse Block reduces visible detail in the editor. Neither action changes the logic's runtime behavior.

Disable Block

Use Disable Block to temporarily exclude logic while investigating an issue or comparing two approaches. Disabled blocks remain on the canvas, but their behavior is excluded from generated code.

A disabled block is not a long-term replacement for saved checkpoints. Review the enabled and disabled state of important blocks before testing and publishing.

Delete Block

Use Delete Block when the selected logic is no longer needed. Check nested blocks and surrounding connections before deleting; removing a parent or connected group may affect other logic.

Canvas Menu and Clipboard Import

Right-clicking an empty part of the canvas opens its contextual menu. The documented Clipboard Import action imports compatible block data.

Reusing Blocks Between Modules

To copy reusable logic:

1. Open the source Cloud Flow module.
2. Right-click the desired block and choose Clipboard Export.
3. Open the destination Cloud Flow module.
4. Right-click an empty part of the canvas and choose Clipboard Import.
5. Place and connect the imported block structure as needed.
6. Review all table, query, Connection, file, and Flow Share references.
7. Save and test the destination module.

Cloud Flow clipboard import is for compatible programming blocks, not arbitrary JavaScript source or frontend Page Elements. Browser clipboard permissions may affect the operation.

When the same helper is needed by many modules, consider implementing it once and making it available through Flow Share, rather than repeatedly copying it.

Organizing Cloud Flow Logic

For larger modules, group blocks around distinct responsibilities:

Input and Initialization
  Read incoming values or initialize module state

Validation and Authorization
  Validate the input and permitted operation

Data and Services
  Read or update records
  Call supported Connections or external services

Result and Error Handling
  Interpret outcomes
  Prepare and return the appropriate result

This is a conceptual arrangement, not a required Cloud Flow structure or set of block labels.

Use procedures for logic reused within a module. Use Flow Share when several backend modules need the same runtime helper or value. For shared modules, load order matters: Background Tasks load before Web Hooks, and modules that provide Flow Share dependencies must be initialized before their consumers where required.

For shared-module setup, see Managing Cloud Flow and Flow Share.

Custom Code and Code Expression

Cloud Flow supports JavaScript alongside visual programming blocks.

Block	Appropriate Use
Custom Code	Execute a focused group of JavaScript statements.
Code Expression	Compute a value for another block using one JavaScript expression.

For example, a Code Expression can compute a value:

Number(quantity) * Number(unitPrice)

A Custom Code block can perform several related steps:

const normalizedEmail = String(email || '').trim().toLowerCase();
const requestSummary = {
  email: normalizedEmail,
  submittedAt: new Date().toISOString()
};

These examples use ordinary JavaScript and assume their variables are intentionally available in the relevant code context. Local declarations in a custom code block do not automatically become shared values accessible from other blocks or modules.

Server-Side Runtime

Custom Code executes in Cloud Flow's controlled Node.js runtime, not in the browser. It can use the broader ioLoop Server API, configured Connections, and an allowlisted set of Node.js modules and SDK libraries where supported.

Do not assume browser-specific globals such as window or document are available. Also do not assume an unrestricted Node.js package environment; use the documented require(...) allowlist and available SDKs.

The Server API, including $io.db, provides additional methods and functionality beyond the Client API used by browser-side Page Flow and custom frontend JavaScript.

For details, see Node.js Runtime and SDK Libraries, Cloud Flow Custom Code, and Server API.

Saving Cloud Flow

Choose Save to retain the current module's edited logic in the Project development state.

When saving, ioLoop generates the JavaScript used by that module in the backend runtime. It validates enabled Custom Code and Code Expression blocks. Invalid JavaScript prevents saving and produces an error for correction. Disabled code blocks are excluded from that validation path while disabled.

Save-Time Validation Versus Runtime Behavior

A successful save does not guarantee that the workflow will operate correctly at runtime. It does not verify that:

• Database records exist or that a query returns the intended results.
• A Connection is configured correctly or an external service is available.
• The caller is authorized to use the Web Hook.
• Flow Share dependencies have been initialized correctly.
• A file operation succeeds.
• All asynchronous success and failure paths are handled correctly.

Test the saved module through its intended runtime path.

Unsaved Changes

If you leave the editor with unsaved changes, ioLoop prompts before discarding them. Save work you want to retain before closing.

Testing and Publishing

Saving, testing, and publishing are separate activities.

Action	Meaning
Save	Retain the module's development logic and generate its backend JavaScript.
Start Test / Stop Test	Control the Cloud Flow test runtime from the Cloud Flow management area.
Preview	Test saved frontend Pages and Forms, including interactions that call Cloud Flow.
Logs	Inspect supported Cloud Flow runtime activity and errors.
Publish Project	Release the Project's development changes to the published application.

A Background Task should be tested according to the behavior implemented inside it, such as initialization or an internal timer. A Web Hook should be tested from its intended caller, using appropriate request data and access conditions.

During Preview, built-in Database operations use the development database. Treat external integrations and services separately: their effects depend on the configured Connections and provider environment. Test carefully when a Cloud Flow may modify external systems.

For details, see Testing and Logs and Development and Production Data.

Example: Build a Web Hook Response

Suppose an application needs a Web Hook to validate an incoming request and return a result to Page Flow.

1. Prepare the Module

1. Create or select a Web Hook in Backend → Cloud Flow.
2. Check its name, HTTP method, and access settings in the management area.
3. Choose Edit Flow.

2. Assemble the Logic

1. Add blocks that read the supported request data.
2. Validate the required values.
3. Add conditional handling for missing or invalid input.
4. Build a success or error result using the appropriate result blocks.
5. Configure the Web Hook response on each necessary outcome path.

Conceptually:

Receive request
  If required input is missing
    Return a useful error result
  Otherwise
    Process request
    Return a success result

This is pseudocode, not an exact block sequence or API signature. Consult the Web Hooks guide and generated block references for specific response blocks and inputs.

3. Save and Test

1. Save the Cloud Flow module.
2. Start the test runtime as needed.
3. Invoke the Web Hook through its intended test caller.
4. Review Logs and the caller's response.
5. Test valid input, invalid input, unauthorized access, and failure handling.
6. Confirm the Page updates correctly when a Page Flow caller receives the result.

This basic structure can later be expanded with Database, file, Connection, or Flow Share operations.

Troubleshooting

Issue	What to Check
Expected logic does not run	Module type, enabled blocks, execution behavior, calls to procedures, and intended runtime path. Do not assume Flow Start is required.
Blocks cannot connect	Whether the statement/value connections and accepted types match.
Copied logic fails	References retained from the original module, missing dependencies, and correct placement of imported blocks.
Save is rejected	JavaScript errors in enabled Custom Code or Code Expression blocks.
Save succeeds but runtime fails	Request data, authorization, logs, async handling, Database state, Connections, or missing dependencies.
Web Hook response is incorrect	Request inputs, conditional paths, response handling, and result shape.
Shared helper is unavailable	Flow Share keys, exporting module behavior, and module load order.
Code behaves as if in a browser	Remove dependencies on browser-only APIs and use the documented Server API.
Published behavior has not changed	Confirm that the module was saved and the Project was published.

For systematic diagnosis, see Testing and Logs.

Good Practices

• Keep the logic readable. Organize blocks around input, validation, processing, and results.
• Understand runtime execution. Flow Start is an organizational marker, not a mandatory runtime root.
• Keep behavior with the right module. Use request/response logic in Web Hooks and self-contained logic in Background Tasks.
• Use block Help and the Programming Guide. Verify specific inputs rather than guessing.
• Handle asynchronous results. Use completion or error behavior before consuming results.
• Use comments purposefully. Document business rules and dependencies.
• Reuse logic deliberately. Use Clipboard Export/Import for compatible block structures or Flow Share for runtime helpers across modules.
• Keep secrets out of logs. Log enough to debug without exposing sensitive information.
• Save and test incrementally. Verify both successful and failed operations before publishing.

Common Mistakes

Avoid these patterns:

• Assuming every block must be connected beneath Flow Start to run.
• Assuming Background Tasks have separate scheduling settings.
• Confusing Canvas Search with Toolbox Search.
• Treating collapsed blocks as disabled blocks.
• Leaving critical logic disabled after testing.
• Importing blocks without reviewing references to source resources.
• Using a large Custom Code block where visual blocks would explain the workflow better.
• Assuming frontend Client APIs and Cloud Flow Server APIs have identical capabilities.
• Trusting unvalidated request data or treating the possession of a Web Hook URL as authorization.
• Treating a successful Save as proof of successful runtime execution.
• Forgetting to publish saved development changes.

The Cloud Flow Editor is most effective when the canvas remains understandable and the logic is tested through its actual runtime path. Use blocks to express the workflow, JavaScript for focused operations, and the supporting Cloud Flow guides for module settings and execution details.

Technical Reference

• Cloud Flow Blocks
• Cloud Flow Custom Code
• Server API
• Result Objects

Related Topics

• Cloud Flow
• Cloud Flow Types
• Managing Cloud Flow
• Node.js Runtime and SDK Libraries
• Background Tasks
• Web Hooks
• Flow Share
• Access Security
• Testing and Logs