Data and Cloud Flow

Page Flow runs in the user's browser. Cloud Flow runs on the server. Both can participate in the same ioLoop application workflow, but they have different responsibilities and security boundaries.

Use Page Flow to coordinate the interface, work with Project data through permitted client-side operations, and respond to results. Use Cloud Flow when processing requires trusted server-side execution, protected credentials, authorization-sensitive rules, or other Backend capabilities.

Not every Database operation needs Cloud Flow. Page Flow can read and modify Project records through supported client-side operations when the current user's access permissions allow it.

For the exact inputs, outputs, and behavior of individual blocks, see Database Blocks, General Blocks, and HTTP and Web Hooks.

Choosing Where Logic Runs

Requirement	Recommended Approach
Load records the current user is allowed to read	Page Flow Database operations.
Display records in a Data Table or custom Data Design	Page Flow with the relevant Widget or rendering behavior.
Create, update, or delete records permitted by Database access rules	Page Flow Database operations, when no additional trusted processing is required.
Apply a browser-side filter or update an element	Page Flow.
Validate input for immediate user feedback	Page Flow, with trusted validation for protected rules.
Use a private API key or provider credential	Cloud Flow or a suitable trusted Integration.
Enforce a rule that must remain valid even if the browser is modified	Trusted Backend processing, including Cloud Flow when appropriate.
Perform a protected operation across multiple records or systems	Cloud Flow or another appropriate Backend capability.
Call server-side processing and show the result	Page Flow invokes Cloud Flow, then handles success or failure.

Choose based on the trust required by the operation, not simply on whether data is involved.

Working with Project Data in Page Flow

Page Flow provides Database blocks for working with Project tables and data results. These blocks support common application tasks such as loading lists, finding a record, creating a new record, updating an existing record, or deleting a permitted record.

Common Database Blocks

Block	Purpose
Data Table Name	Identifies the Project table used by an operation.
Data Query Name	Identifies a configured named query.
Data Read	Starts a table read, optionally using a named query, input criteria, and a page size.
Data Lookup	Finds matching records using criteria and places results in a dataset.
Data Lookup with ID	Looks up one record by its record ID, with success and error handling.
Data Add Record	Starts a create operation using a record data object.
Data Update Record with ID	Starts an update for the identified record using supplied values.
Data Delete Record with ID	Starts a delete operation for the identified record.
Data Status	Waits for a selected data operation and runs the corresponding success or error statements.
Data Record List / Data Record Count	Access records or counts available in a dataset.
Data Read Next / Data Read Previous	Move through the pages of a dataset-backed read.
Clear Dataset	Clears a selected dataset from the data runtime.

These are block descriptions, not a complete list of their inputs. Refer to the Database Blocks reference for precise configuration.

Tables, Queries, and Datasets

These concepts play different roles in a Page Flow data operation:

Concept	Role
Project table	The Database table containing the records.
Named query	A configured query that can be selected for supported read operations.
Input criteria	Values supplied to a supported read or lookup operation to identify the requested data.
Dataset name	Identifies the dataset used by Page Flow to hold and work with data results for a particular operation.
Record ID	Identifies a particular existing record for operations that target it.

For example, a Customers Page might read records from the Customers table into a dataset named CustomerResults, using a named query to request the records relevant to the current view.

The Page Flow can then use the resulting dataset to populate an interface, show a record count, or work with individual records after the operation completes.

A dataset name is not a Database table name, and the position of a record within a dataset is not a substitute for its record ID.

Reading and Displaying Records

A common read workflow is:

1. Identify the Project table to read.
2. Select a supported named query or supply the appropriate criteria, if needed.
3. Choose a dataset name and any supported page-size options.
4. Start the read operation.
5. Handle completion through the appropriate data-operation status or callback behavior.
6. On success, use the available records to update the Page, Data Table Widget, or Data Design rendering.
7. On failure, display a useful message and provide a way to retry when appropriate.

For example, a customer directory may load the first page of customers when the Page opens. A search action can run another permitted query, then replace the visible results once the new operation succeeds.

Do not assume the records are available immediately after a block starts a read. Use the completion behavior provided by the relevant blocks before accessing results that depend on the operation.

Named Queries and Criteria

Named queries help a Page Flow use a configured query instead of embedding the entire selection process in the visible Page behavior.

They are useful when a Page needs data based on:

• A search term or user-selected filter.
• A record category or status.
• A related customer, order, or other record.
• The current user's permitted data scope.
• A repeatable application data view.

Pass the inputs expected by the chosen query. A query name and its criteria must be configured consistently with the underlying Database query.

A named query is not automatically an access-control rule. Its returned data must still be governed by the Project's appropriate Database permissions and Backend authorization.

Creating and Updating Records

Use supported client-side create and update operations when the action is permitted to the current user and does not depend on additional server-trusted business rules.

A typical create workflow is:

1. Collect the required values from Page Elements or a Form.
2. Validate them for helpful user feedback.
3. Prepare the record data object expected by the selected operation.
4. Start Data Add Record.
5. Handle the operation's success or error result.
6. Refresh the relevant dataset, Data Table, or other visible content after a successful change.

An update workflow must also identify the existing record being changed. Use the appropriate record ID rather than matching only a display name, row position, or other value that may not be unique.

For updates or deletes, confirm that the current user is authorized to perform the operation. Hiding an Edit or Delete control is not sufficient protection.

Refreshing and Paging Data

After creating, updating, or deleting data, the Page may need to load fresh records or update its visible state.

The Database block reference includes dataset refresh options on supported write operations, along with Data Read Next and Data Read Previous for paged data.

Choose the behavior that matches the interface:

• Refresh results when users expect the current list to reflect completed changes.
• Load the next or previous dataset page when browsing larger result sets.
• Clear or replace an old dataset when a new query should no longer use the previous results.
• Keep the visible search term and filter state consistent with the data being displayed.

Refresh behavior depends on the chosen blocks and Widget configuration. Do not assume every write operation automatically refreshes every Page Element or Widget that shows related records.

Handling Asynchronous Data Operations

Several Database blocks start an operation rather than returning all results immediately. The Data Status block can wait for a selected operation for a table and dataset, then run separate success or error statements.

A conceptual flow looks like this:

Page opens
  Start Data Read for Customers / CustomerResults
  Wait for read completion using Data Status
    On success
      Read the current dataset
      Populate the visible customer list
    On error
      Show a useful loading error

This example describes the flow of control; it is not a literal block sequence or generated JavaScript.

Be consistent about the table, dataset name, and operation being tracked. If the completion handler watches a different operation or dataset from the one started, the expected result may not be handled.

See Events and Startup for general asynchronous execution guidance.

When to Use Cloud Flow

Use Cloud Flow when a workflow needs server-side trust or must run independently of the browser's control over submitted values.

Common reasons include:

• Calling external services with private API keys or other secrets.
• Enforcing authorization-sensitive rules.
• Applying business rules consistently for every caller.
• Processing files through protected server-side operations.
• Coordinating complex or related data changes.
• Running backend processing that cannot safely depend on a visitor's browser.
• Exposing an appropriately configured Web Hook for a Page or an external system to invoke.

For example, a registration Page can collect attendee information and check required fields in Page Flow. If the application must enforce a maximum event capacity, the trusted Backend workflow should recheck and enforce that limit when accepting the registration. A browser-side availability indicator alone cannot enforce the rule.

Cloud Flow Does Not Replace Page Flow

Cloud Flow handles trusted processing, while Page Flow remains responsible for the user-facing experience.

Page Flow	Cloud Flow
Responds to the user's action.	Receives and processes a supported server-side request.
Reads the relevant Form values and permitted context.	Validates the request and enforces protected rules.
Sends the information required for processing.	Uses trusted credentials and Backend operations where appropriate.
Shows loading or processing feedback.	Returns the operation outcome or appropriate response.
Updates the Page after completion.	Does not directly control the visitor's browser interface.

This division keeps presentation behavior separate from decisions that must be trusted.

Invoking Cloud Flow from Page Flow

The Page Flow block reference documents Cloud Flow Invoke Hook, which sends an HTTP POST request to a selected Web Hook Cloud Flow and provides success and failure branches.

The related Cloud Flow: URL of Web Hook block identifies the URL of the Web Hook Cloud Flow to invoke.

Typical Setup

1. Configure the server-side Cloud Flow and its Web Hook in the Project's Backend.
2. Define the input the Cloud Flow expects and the result it should return.
3. In Page Flow, identify the required Cloud Flow Web Hook.
4. Prepare an object containing the values the server needs.
5. Use Cloud Flow Invoke Hook to call it.
6. Put result-dependent Page behavior inside the supported success and failure paths.
7. Preview the complete interaction, including unauthorized and invalid requests.

For example, a Request Approval action might send a record ID, a decision, and a note to a Web Hook Cloud Flow. The server checks that the request is allowed, performs the operation, and returns the outcome. Page Flow then updates the displayed status or presents an error.

Only send the data that the Backend operation needs. Do not put private credentials into the Page Flow or rely on browser-provided identity or role values as trusted proof of permission.

Working with Cloud Flow Responses

The documented Cloud Flow invocation block provides:

Path or Block	What It Provides
On success	A callback path for the successful Web Hook invocation.
On failure	A callback path for an unsuccessful invocation.
HTTP Data	The response data available within supported success callback contexts.
HTTP Error	Error information available within supported failure callback contexts.

Place follow-up logic in the appropriate callback branch. Avoid starting a Cloud Flow call and immediately assuming that a result is ready in the next unrelated statement.

A successful HTTP invocation does not necessarily prove that the requested business operation succeeded. If the Cloud Flow response includes its own operation status, check that status before showing a final confirmation or performing the next user-facing action.

For exact block inputs and callback behavior, see General Blocks and HTTP and Web Hooks.

Calling External HTTP Services

Page Flow also provides supported HTTP GET and POST blocks. Those requests run from the browser-side environment.

Use browser-side HTTP operations only when the endpoint and data are appropriate for client-side access and the required browser/network restrictions permit the request.

If a third-party service requires a private key, a protected authorization step, or trusted request signing, use an appropriate Cloud Flow or Integration-backed server-side workflow instead. A credential placed in Page Flow or browser-side Custom Code should be treated as exposed to the visitor.

Result Objects and Error Handling

Many ioLoop workflows use a result object with these fields:

Field	Meaning
status	Indicates the result's success state for that result-object pattern.
data	Carries the returned data.
err	Carries error information or a message.

The Result Objects reference documents New Result Object, Result Status, Result Data, and Result Error, among other blocks. In that pattern, status is a Boolean value.

A conceptual response could contain:

{
  "status": true,
  "data": { "registrationId": "REG-1042" },
  "err": ""
}

This example illustrates a result-object pattern. It is not a guarantee that every Database, HTTP, or Cloud Flow operation returns this exact structure. Use the output and callback behavior documented for the operation you are handling.

Checking Results Before Using Data

When the operation returns a result object:

1. Inspect the success status.
2. If successful, read the expected data and confirm that it contains the values the next step requires.
3. If unsuccessful, use the available error information to display an appropriate message.
4. Avoid continuing a dependent workflow with incomplete or failed results.

When an operation instead provides separate success and failure callbacks, handle the relevant returned data or error in those branches.

User-Facing Error Messages

Good errors tell users what they can do next without exposing implementation details.

Situation	Example Message
Records could not be loaded	We couldn't load the records. Try again.
A record is no longer available	This item may have changed. Refresh and try again.
Permission was denied	You don't have permission to complete this action.
Server processing failed	We couldn't complete the request. Please try again.
A required selection is missing	Select an item before continuing.

Do not display secret tokens, private provider responses, or sensitive diagnostic information in messages to visitors.

Example: Event Registration with Capacity Enforcement

Consider an application where a visitor selects an event and registers for it.

1. Display the Event

A Page can use permitted Project data operations to load event details, display the event title, and show the registration control.

The Page may show an available-seat count, but the number displayed in the browser is informational and can become outdated.

2. Collect Registration Details

A Button opens a registration Form as a modal and passes the selected event as shared context.

The Form collects the attendee's information and checks required fields. Page Flow prepares the data needed for the registration request.

3. Process the Request on the Server

Page Flow invokes a configured Web Hook Cloud Flow with the required event and registration values.

The trusted Backend processing should:

1. Validate the request and applicable permissions.
2. Check the current event registration rules and capacity.
3. Apply the relevant rules when accepting or rejecting the registration.
4. Save the registration only if the rules permit it.
5. Return a result that the Page or Form can use.

For capacity limits to remain reliable under simultaneous requests, the Backend implementation must protect against conflicting registrations; merely checking capacity earlier in the browser is insufficient.

4. Respond to the Result

After the Cloud Flow call completes:

• On confirmed success, show the registration confirmation and refresh the relevant event information.
• On a business-rule rejection, explain that the event is no longer accepting registrations or that the selected action is unavailable.
• On a technical failure, show an appropriate error without claiming the registration succeeded.

The exact implementation depends on the configured Cloud Flow and its documented response format.

This approach combines a responsive browser-side experience with centrally enforced processing, without making every Page data read a server-side custom workflow.

Security and Access Control

Page access, Database access, and Backend authorization are related but separate controls.

Control	Purpose
Page access	Determines which Project Users or visitors may open a Page under its configured access rules.
Database access rules	Govern which data operations and records a caller may access through permitted interfaces.
Page Flow	Coordinates the user interface; it does not provide a trusted security boundary.
Cloud Flow / trusted Backend logic	Can enforce protected rules and carry out appropriate server-side operations.

Important implications:

• Hiding a Page Element or disabling a Button does not prevent someone from attempting the corresponding operation another way.
• Passing a record ID or role in browser-side data does not establish that the user is authorized to act on it.
• Restricting a Page does not automatically authorize every Database operation or Web Hook it uses.
• A Web Hook should validate the caller and request according to the protection required by the operation; being called from a Project Page is not, by itself, sufficient authorization.
• Credentials and private service configuration belong in trusted Project capabilities, not in Page Flow code or Page content.

Use Page Settings, Database, and Cloud Flow for the relevant security configuration.

Testing Data and Cloud Flow Interactions

Preview the Page or Form from the actual workflow that starts the operation.

Test Case	What to Verify
Initial load	The intended records load and the Page becomes usable.
No results	The Page shows a helpful empty state.
Read failure	An error is shown without presenting old results as current data.
Create or update	The operation changes the intended record and the UI refreshes after success.
Delete	The intended record is removed only after the permitted operation succeeds.
Named query / filter	The correct criteria and dataset are used.
Async completion	Dependent logic runs only after the necessary result is available.
Cloud Flow success	The expected result is returned and reflected in the UI.
Business rejection	A rejected request does not appear as successful.
Server or network failure	The Page handles the failure and provides recovery guidance.
Permissions	Users cannot read or modify records or invoke protected operations beyond their authorization.
Repeated actions	Rapid repeated clicks do not lead to unintended duplicate operations.

If results can be loaded from multiple searches or filters, also test requests that complete out of order. The Page should not allow an older response to replace the results of a newer user selection unless that is the intended behavior.

Remember that Preview can execute actual data requests and Backend workflows depending on the Project environment. Use appropriate test data and connections.

For additional guidance, see Previewing and Troubleshooting.

Good Practices

• Choose the simplest safe execution path. Use permitted Page Flow Database operations for ordinary data tasks; use Cloud Flow when trusted processing is required.
• Keep data operations explicit. Use clear table, query, dataset, and record identifiers.
• Handle completion before consuming results. Use Data Status or the supported success/failure callbacks for the relevant operation.
• Refresh intentionally. Update visible data after confirmed changes rather than assuming every Widget refreshes automatically.
• Return useful results. Design server-side responses so the Page can distinguish success, rejection, and failure.
• Minimize client-visible data. Request and display only information the user is permitted to access and that the interface actually needs.
• Enforce protected rules on the server. Recheck authorization and business conditions during trusted operations.
• Keep credentials private. Never embed provider secrets in browser-side blocks or JavaScript.
• Test more than the successful path. Include empty results, denied access, stale records, repeated submissions, and failed server calls.

Common Mistakes

Avoid these patterns:

• Sending every Database read through Cloud Flow even though a permitted client-side read would suffice.
• Assuming that a named query or hidden field automatically limits a user's Database permissions.
• Treating the selected row index as a durable record identifier.
• Reading dataset results immediately after starting an asynchronous operation.
• Using mismatched dataset names between a data operation and its completion handler.
• Treating an HTTP success callback as proof that a business transaction completed successfully.
• Assuming every operation returns the same status, data, and err structure.
• Placing secret keys or protected business rules in Page Flow or browser-side Custom Code.
• Trusting browser-provided record IDs, prices, roles, or status values without the necessary Backend validation.
• Updating a Data Table or showing success before a record change is confirmed.
• Testing only with an administrator or only when all external services are available.

Page Flow and Cloud Flow are most effective when the browser handles interaction and permitted data access, while the server handles operations requiring trust. Keep the execution boundary clear, check the outcome of every dependent operation, and give users accurate feedback.

Related Topics

• Page Flow
• Choosing Blocks
• Events and Startup
• Forms and Widgets
• Previewing and Troubleshooting
• Database Blocks
• General Blocks — Cloud Flow Invoke Hook
• HTTP and Web Hooks
• Result Objects
• Client API
• Cloud Flow
• Cloud Flow Blocks
• Server API