Appearance
Cloud Flow
Cloud Flow is ioLoop's server-side programming and workflow environment. Use it when a Project needs trusted processing, protected integrations, server-side Database or file operations, Web Hooks, Background Tasks, or functionality that should run independently of a user's browser.
Cloud Flow complements the Frontend and Project Database. A Page can collect input and initiate an operation, while Cloud Flow performs the server-side work and, when appropriate, returns a result to the caller.
Cloud Flow supports visual programming blocks and custom JavaScript in a controlled Node.js runtime. Creators can use either approach or combine them within the same workflow.
When to Use Cloud Flow
Choose Cloud Flow when an operation needs a server-side execution environment or capabilities beyond the browser's role.
| Requirement | Recommended Approach |
|---|---|
| Respond to clicks, update visible content, or open modal Forms | Page Flow or custom frontend JavaScript. |
| Read or change Project records permitted to the current user | Supported frontend Database operations may be sufficient. |
| Enforce protected business rules or record-specific authorization | Cloud Flow with appropriate Database and workflow access checks. |
| Use private credentials or call protected external services | Cloud Flow with configured Connections. |
| Receive an HTTP request from a Page or external service | Cloud Flow Web Hook. |
| Run backend work without exposing an HTTP endpoint | Background Task. |
| Share backend helpers or runtime values between modules | Flow Share, commonly initialized by a Background Task. |
| Use server-only Database, file, or integration functionality | Cloud Flow blocks or the ioLoop Server API. |
Not every Database operation needs Cloud Flow. ioLoop's frontend tools and custom JavaScript can use permitted Client API operations directly. The Server API available in Cloud Flow has broader functionality than the Client API, including additional Database methods; the two APIs should not be assumed to have identical capabilities or signatures.
For frontend data integration, see Using Database from Pages. For backend Database usage, see Using Database.
Cloud Flow Types and Components
Cloud Flow brings together several related capabilities:
| Component | Role |
|---|---|
| Background Task | Backend processing that is not exposed as a Web Hook; it can also provide shared runtime helpers. |
| Web Hook | A request-and-response workflow that can be invoked through an HTTP request. |
| Cloud Flow Editor | The visual programming canvas used to build and save workflow logic. |
| Server-side JavaScript | Custom code that runs in ioLoop's controlled Node.js runtime and can use supported Server APIs and libraries. |
| Flow Share | Shares runtime values and helper functions across backend modules; it is not durable storage. |
| Connections | Provide configured access to external services and their protected credentials. |
| Testing and Logs | Help verify and diagnose server-side execution. |
The two primary Cloud Flow types are Background Task and Web Hook. Choose based on how the operation needs to be invoked—not merely on whether it performs work in the background.
Cloud Flow also supports AI Agent-related backend behavior. Agent-specific functions and tools are described under AI Agents.
For type selection, see Cloud Flow Types.
How Cloud Flow Works with the Project
Cloud Flow often participates in workflows that begin elsewhere in an ioLoop Project.
For example, consider an event registration application:
- A Page displays an event and opens a registration Form or custom modal interface.
- Page Flow or custom frontend JavaScript collects the values and invokes a Cloud Flow Web Hook.
- Cloud Flow validates the request, checks authorization and event capacity, and performs permitted Database operations.
- If needed, Cloud Flow calls an external service through a configured Connection.
- The Web Hook returns a result, which the frontend uses to display confirmation or an error.
This is one implementation pattern, not a requirement for every registration Form. Simple permitted data operations can use frontend capabilities directly. Use Cloud Flow when protected rules, server-only functions, or integration work justify a backend workflow.
For the frontend-to-backend pattern, see Calling Cloud Flow from Pages.
Building and Reusing Backend Logic
In the Cloud Flow Editor, visual blocks express common operations and workflow structure. Custom Code and Code Expression blocks provide JavaScript where code is clearer or more suitable.
Cloud Flow JavaScript runs server-side, not in the browser. It can use supported $io Server APIs, configured Connections, and curated Node.js modules or SDK libraries available through the controlled runtime. Browser-specific objects such as window and document are not part of that environment.
Shared backend logic can be placed in Background Task modules and exposed through Flow Share. Module load order matters when a module depends on helpers initialized by another module. Flow Share is runtime sharing, not a substitute for persistent records or files.
For implementation details, see Cloud Flow Editor, Node.js Runtime and SDK Libraries, and Flow Share.
Security, Testing, and Publishing
Cloud Flow executes trusted server-side code, but running on the server does not automatically make an operation authorized. Configure workflow access and validate untrusted inputs, caller identity, record-specific permissions, and business rules before performing protected actions. Public Web Hooks require particular care.
During Preview, built-in Database operations automatically use the Project's development database. Connections and external services may have separate test/live configurations and can have real effects; verify those settings before testing workflows that call outside systems.
Test workflows through their intended invocation paths, review relevant logs, and verify failure and denied-access cases as well as successful operations. Saving and testing development behavior does not by itself publish changes to the live Project.
For detailed guidance, see Access Security, Testing and Logs, and Publish Project.
In This Section
| Guide | What You Will Learn |
|---|---|
| Cloud Flow Types | Choose between Background Tasks and Web Hooks. |
| Managing Cloud Flow | Create, configure, enable, clone, order, and delete backend modules. |
| Cloud Flow Editor | Work with visual blocks, custom code, the canvas, and saving logic. |
| Node.js Runtime and SDK Libraries | Understand server-side JavaScript, $io APIs, curated libraries, and runtime boundaries. |
| Background Tasks | Design non-endpoint backend workflows and shared helper modules. |
| Web Hooks | Configure request-driven workflows, responses, and external callers. |
| Flow Share | Share runtime helpers and values between backend modules. |
| Access Security | Configure access and enforce authorization and business rules. |
| Testing and Logs | Test workflows and investigate backend execution. |
| Calling Cloud Flow from Pages | Invoke Cloud Flow from frontend interactions and handle results. |
| Using Database | Use Project data and named queries from server-side workflows. |
| Using Files | Process and manage files through backend workflows. |
| Using Connections | Work with configured external services and integrations. |
Technical Reference
Use the Programming Guide for exact block behavior, API parameters, supported methods, and return values:
Good Practices
- Choose the correct trigger. Use a Web Hook for request/response operations and a Background Task for non-endpoint backend work.
- Enforce trusted rules on the server. Validate requests and authorization rather than relying on frontend controls.
- Use the appropriate API. Consult the Server API for backend-only capabilities instead of assuming Client API parity.
- Reuse backend helpers deliberately. Use Flow Share when runtime sharing is suitable and account for module load order.
- Test the full execution path. Check development data, external Connection settings, errors, permissions, and logs.