Managing Cloud Flow

Use Backend → Cloud Flow to create, organize, configure, enable, clone, and remove the Cloud Flow modules used by an ioLoop Project.

A Cloud Flow module can contain backend processing, provide an HTTP Web Hook, or make shared functionality available to other backend modules. Pages, Page Flow, external systems, AI Agents, and other Cloud Flow modules may depend on it, so changes should be made with those dependencies in mind.

This page covers module management in Backend → Cloud Flow. For building the logic inside a module, see Cloud Flow Editor. For an explanation of the module types, see Cloud Flow Types.

Opening Cloud Flow

1. Open the Project in the Project Editor.
2. Select Backend → Cloud Flow.
3. Review the module list, or use New Cloud Flow to create a module.
4. Select an existing module to open its available actions.

The Cloud Flow list can be shown as tiles or as a table-style listing. It provides a central place to find and manage the Project's backend modules.

What the Module List Shows

In tile view, each module appears as a Cloud Flow tile with its name and type. Disabled modules are visually muted.

In table view, the list shows:

Information	Purpose
Name	Identifies the module in the Project.
Type	Distinguishes a Background Task from a Web Hook.
Status	Shows whether the module is enabled or disabled.
Access (Security)	Shows applicable access information. For Background Tasks, the list reflects that they are internal modules.

The list is ordered by Cloud Flow load order. Use the module actions Load Order - and Load Order + to change a module's position.

Use Search to find a module by name and Refresh to reload the list when needed. Select a module to open its action menu.

Module Actions

Select a module to access its available actions.

Action	What It Does
Edit Flow	Opens the Cloud Flow Editor to change the module's logic.
Settings	Opens settings available for that module type.
Access (Security)	Configures Web Hook access. Background Tasks are already internal and do not have the same access configuration.
Load Order -	Moves the module earlier in the load order within its type.
Load Order +	Moves the module later in the load order within its type.
Enable / Disable	Changes the module's enabled state.
Clone	Creates a separate module based on the selected module.
Delete	Removes the module. Check dependent workflows first.

The main Cloud Flow toolbar also provides Start Test, Stop Test, and Logs for working with the test runtime and its diagnostics.

Not every action is a setting inside the Settings dialog. Load order, enabled state, and access are managed through their corresponding module actions.

Creating a Cloud Flow Module

Choose New Cloud Flow, then select the type of module needed.

Type	Purpose	Initial Configuration
Background Task	Backend code that is not exposed as an HTTP Web Hook; it can also provide shared helpers.	Enter a module name. There is no separate trigger or scheduling configuration.
Web Hook	A backend request handler that can receive HTTP requests and return responses.	Configure its Web Hook name, HTTP method, and response streaming as applicable.

New modules start enabled with an initial load order. Once the module has been created, select Edit Flow to implement its logic.

Creating a Background Task

1. Select New Cloud Flow → Background Task.
2. Enter a meaningful module name.
3. Save the new module.
4. Select Edit Flow to add its server-side logic.
5. Save the flow and test its intended behavior.

Background Tasks do not have a separate trigger, schedule, or timer setting in Cloud Flow. Their behavior is implemented inside the task's own logic. For example, a Background Task can initialize a timer to perform periodic work, or it can provide reusable helper functions without implementing periodic processing.

Module load order controls when modules are loaded relative to one another. It is not a schedule for Background Tasks.

For design and runtime considerations, see Background Tasks.

Creating a Web Hook

1. Select New Cloud Flow → Web Hook.
2. Enter the Web Hook name.
3. Choose the Hook HTTP Method, such as GET or POST, as appropriate.
4. Configure Response Streaming when the Web Hook needs supported streaming behavior.
5. Save the module.
6. Review the available test URL and published URL pattern.
7. Open Edit Flow to implement request processing and the response.
8. Configure Access (Security) before allowing intended callers to use it.

The Web Hook settings panel displays the development test URL and the published URL pattern. Use these displayed URLs rather than constructing endpoint URLs from assumptions.

For request handling, streaming options, and caller behavior, see Web Hooks.

Module Settings

Use Settings for the properties specific to the selected module type.

Module Type	Settings
Background Task	Module name.
Web Hook	Name, Hook HTTP Method, and Response Streaming.

The remaining management concerns—such as load order, enabled state, and Web Hook access—have separate controls in the module list.

Naming Modules

Choose a stable, recognizable name that describes what the module does.

Examples include:

• ProcessRegistration for a Web Hook that handles registration requests.
• UpdateOrderStatus for a Web Hook that processes order changes.
• SharedValidationHelpers for a Background Task that exports common validation functions.
• RefreshCatalog for a Background Task whose own logic implements catalog refresh behavior.

Names used by callers or other Project configuration should be treated as dependencies rather than casual labels.

Changing Web Hook Settings

Changing a Web Hook's name changes the URL that callers use. Changing its HTTP method or response behavior may also require changes to the callers.

Before saving such a change:

1. Identify Pages and Page Flow operations that invoke the Web Hook.
2. Review external systems and configured integration callbacks that use its URL.
3. Check the HTTP method, request format, and response expected by each caller.
4. Make the change and update callers as required.
5. Test the development endpoint through each important invocation path.
6. Publish and verify the updated caller behavior when ready.

Do not assume an existing integration or external caller will automatically follow a renamed Web Hook.

Enabling and Disabling Modules

Use Enable / Disable to control whether a Cloud Flow module is enabled.

This is useful when a workflow should not be available, or when a module is being prepared before it is used. Consider the dependencies before disabling it.

• Disabling a Web Hook can prevent callers from completing requests that depend on it.
• Disabling a Background Task can affect its own processing and any shared helpers that it would otherwise provide.
• A disabled module should not be assumed to remain available to other modules simply because its name or references still exist.

Before enabling a changed module, review its logic, caller expectations, and any potentially consequential operations. For example, a Background Task whose logic starts a timer should be reviewed for repeated processing when its runtime is started.

Module Load Order

Cloud Flow modules load in a defined type order:

1. Background Tasks
2. Web Hooks
3. AI Agent modules

Within each type, lower load-order values are loaded before higher values.

Use Load Order - and Load Order + to change a module's position within its type. This is important when a module must initialize shared runtime functions or values before another module uses them.

Example: Shared Helpers

Consider three modules:

Background Task: SharedValidationHelpers
  Defines helper functions
  Exposes helpers through Flow Share

Web Hook: CreateRegistration
  Reads the shared validation helper
  Validates and processes an incoming request

Web Hook: UpdateRegistration
  Reads the same helper
  Validates and processes an incoming request

The shared Background Task loads before the Web Hooks, making the exported helper available for their request-handling logic when initialized correctly.

If one Background Task reads values exported by another Background Task, arrange the providing module earlier within the Background Task load order.

Load order is not execution scheduling. It neither defines how frequently a Background Task runs nor replaces timer or other control logic implemented within the task.

For complete guidance on runtime sharing, see Flow Share.

Managing Shared Background Task Modules

Background Tasks are useful as common backend modules, not only as modules that perform ongoing work.

Typical shared functionality includes:

• Validation and normalization helpers.
• Common authorization helper functions.
• Shared wrappers around supported Database or Connection operations.
• Small runtime configuration objects.
• Re-creatable runtime caches.

Use Flow Share to expose values or helper functions that other backend modules need. Shared values are runtime state, not persistent records; store durable application data in Database or appropriate file storage.

When changing a shared module:

1. Identify all consumers of its Flow Share values or functions.
2. Check that the exported names and function expectations remain compatible.
3. Review load order and enabled state.
4. Test dependent Web Hooks, Background Tasks, and AI Agent modules.
5. Test again after restarting the test runtime when initialization behavior matters.

Be especially careful when modifying a helper that handles authorization or other shared business rules. One change can affect multiple backend workflows.

Editing Flow Logic

Select Edit Flow to open a module's logic in the Cloud Flow Editor.

The editor lets you assemble visual blocks, configure inputs, use focused JavaScript, and save the module's generated backend logic.

Use Edit Flow to change what the module does. Use Settings and the module list actions to change how the module is identified, loaded, enabled, or made available.

After changing logic, save and test the module through its intended usage path. A successful save does not prove that runtime input, Database operations, external Connections, or Flow Share dependencies will behave correctly.

For exact block behavior and API signatures, use the Cloud Flow Blocks and Server API references.

Cloning Modules

Use Clone when you want a separate module based on existing logic.

Examples include:

• Creating a variation of an existing Web Hook for a different operation.
• Reusing a shared backend implementation while developing an alternative.
• Experimenting with a new workflow without changing the original module.

After cloning, review the new module rather than assuming it is immediately ready to use.

Review	Why It Matters
Name	The clone needs an unambiguous identity.
Type and settings	Web Hook methods, response settings, and usage may need adjustment.
Access (Security)	The new Web Hook may need different callers or restrictions.
Load Order	The new module may compete with or depend on existing shared modules.
Enabled state	An enabled clone can have consequences if its logic performs active processing.
Flow Share	Cloned exports may reuse names or interfere with shared expectations.
Callers	Pages and external systems are not automatically redirected to the clone.

A clone is not a substitute for an operational backup or rollback plan. It creates a separate module for further work; it does not automatically migrate callers or restore past runtime state.

For Background Tasks that initialize timers or perform other work from their own logic, review whether keeping both the original and clone enabled could lead to duplicated processing.

Deleting Modules

Delete a module only after checking that it is no longer needed.

Before deleting, review potential dependencies:

• Page Flow and frontend Client API calls to Web Hooks.
• External systems and integration callbacks.
• Other backend modules.
• AI Agent functions or other agent-related processing.
• Flow Share values exported or consumed by the module.
• Operational procedures that depend on a Background Task.
• Published application behavior that still expects the module.

A safe deletion approach is:

1. Find the module's known callers and consumers.
2. Update or remove those dependencies.
3. Test important workflows without the module, including shared-helper consumers.
4. Remove the module only after the dependencies are addressed.
5. Publish and verify affected application behavior where applicable.

Deleting a module does not automatically repair calls or references left elsewhere in the Project.

Test Runtime and Logs

The Cloud Flow toolbar provides:

Control	Purpose
Start Test	Starts the Cloud Flow development test runtime.
Stop Test	Stops the Cloud Flow development test runtime.
Logs	Opens Cloud Flow log information for review.

Logs can distinguish test and live activity and support searching and diagnosing backend behavior.

Test Cloud Flow through the path by which it will actually be used:

• For a Web Hook called by Page Flow, invoke it from the Page in Preview.
• For a Web Hook called externally, send a representative request to the intended test endpoint.
• For a Background Task, verify its own initialization or processing behavior in the test runtime, including any timers implemented in its logic.
• For Flow Share, test both the exporting module and modules that consume the shared value.

An external application that should act as a Project User can send that user's Web Hook Key in the HTTP Authorization header using the Bearer scheme. The user must be permitted by the Web Hook's Access (Security) rules. For the request format and security requirements, see Web Hooks — Calling as a Project User.

Use test records and appropriate test-mode Connections where possible. Cloud Flow may call external services whose effects are not automatically isolated merely because the Project is under development.

Save, testing, and publishing are separate steps. Saving a Cloud Flow module changes the Project's development state; Publish Project is required to release those changes to the published application.

For detailed testing procedures, see Testing and Logs.

Example: Introducing a Shared Validation Module

Suppose two existing Web Hooks independently validate event registration data. You want to move the repeated validation into a common helper.

1. Create the shared module

Create a Background Task called SharedRegistrationHelpers. Define the reusable validation function in its logic and expose it through Flow Share. No separate schedule or trigger configuration is required.

2. Review load order

Ensure the shared Background Task loads before the Web Hooks that consume the helper. If it depends on other Background Tasks, arrange their order as needed.

3. Update the consumers

Edit the two Web Hooks to read the shared helper and pass the request data they need validated. Keep request-specific authorization and processing within the appropriate trusted workflow.

4. Test the complete behavior

Start the test runtime, exercise each Web Hook through its real caller, and inspect Logs. Test valid requests, invalid input, and authorization failures. Also verify that the helper is available after restarting the test runtime.

5. Publish after verification

Save the affected modules and publish the Project when the updated workflows and dependencies are ready. Verify the published behavior separately.

This example illustrates module management and dependency planning. For implementation details, use Flow Share and Cloud Flow Editor.

Troubleshooting

Issue	What to Check
Web Hook cannot be called	Enabled state, URL, HTTP method, access settings, request input, and whether the intended runtime is available.
Web Hook stopped working after rename	Callers still using the previous URL or method.
A shared helper is unavailable	Provider module enabled state, Flow Share export name, initialization behavior, and load order.
Background Task work is not occurring	Task logic, its initialization or timer behavior, enabled state, test-runtime state, and logs. There is no separate Background Task schedule setting.
Cloned module causes unexpected work	Whether the original and clone are both enabled or export the same Flow Share names.
Cloud Flow saves but fails at runtime	Inputs, caller authorization, Database operations, external services, and asynchronous completion.
Changes are not visible in production	Saved development modules, publishing status, and published callers.
Unexpected results after load-order changes	Which module exports the required helper and whether it loads before its consumers.

Good Practices

• Use meaningful module names. Make purpose and shared responsibility recognizable.
• Keep the module types distinct. Use Background Tasks for non-endpoint logic and Web Hooks for HTTP request/response processing.
• Implement Background Task behavior in its logic. Timers and repeated work are not configured separately in Cloud Flow.
• Review dependencies before changing modules. Web Hook names, Flow Share exports, and module enabled states can affect many callers.
• Manage load order deliberately. Shared providers must be available before consumers need them.
• Keep security explicit. Configure Web Hook access and validate sensitive operations within server-side logic.
• Test through real invocation paths. Include restart-sensitive initialization behavior and failures.
• Use Logs during testing. Make backend operations diagnosable without exposing credentials or sensitive records.
• Publish intentionally. Saving and testing do not release a change to the published Project.

Common Mistakes

Avoid these patterns:

• Expecting Cloud Flow to provide a separate scheduler or trigger setting for Background Tasks.
• Confusing module load order with a task's execution schedule.
• Renaming a Web Hook without updating its callers.
• Leaving a cloned Background Task active without checking for duplicate timer-driven processing.
• Disabling or deleting shared modules without checking Flow Share consumers.
• Assuming a Web Hook is secured solely because its URL is hard to guess.
• Cloning a module and assuming callers now use the clone.
• Using Flow Share for data that must survive runtime restarts.
• Saving a flow and assuming it has already been published or fully runtime-tested.

Cloud Flow management is about keeping backend modules understandable, correctly loaded, appropriately secured, and safely connected to the rest of the Project.

Related Topics

• Cloud Flow
• Cloud Flow Types
• Cloud Flow Editor
• Background Tasks
• Web Hooks
• Flow Share
• Access Security
• Testing and Logs
• Publish Project