Choosing Blocks

Page Flow blocks are organized around the work you want a Page or Form to perform. Start with the intended behavior—such as responding to a button, reading an input, displaying records, or calling Cloud Flow—then choose the block family that supports it.

Most workflows combine several families. For example, a button-driven search may use an event block, input blocks, Database blocks, and Page Content blocks to display the results.

This page helps you select and combine blocks. For exact inputs, output types, options, and runtime behavior, use the Page Flow Blocks reference in the Programming Guide. Many ioLoop blocks also provide a Help action in their right-click menu.

Start with the Behavior You Need

The following table provides a starting point for common Page Flow requirements.

If you need to...	Start with...	Related reference
Run logic when the Page or Form opens	Flow and startup blocks	General Blocks
React to a button or other element event	Event blocks	General Blocks
Make a decision, repeat steps, or calculate a value	Logic, Lists, Math, Variables, or Functions	Page Flow Blocks
Read or change displayed element content	Page Content or Page Action blocks	Page Actions
Read inputs or change element styles and attributes	Input, Style/CSS, or Html/DOM blocks	General Blocks
Open a Form or work with Form data	Forms blocks	Forms Blocks
Refresh or configure Data Table behavior	Widget-related blocks	General Blocks and Page Actions
Render a Data Design or interact with a rendered item	Data Design-related blocks	Content Blocks
Read or change permitted Project records	Database blocks	Database Blocks
Invoke trusted server-side processing	Cloud Flow blocks	General Blocks
Make a supported HTTP request	HTTP blocks	HTTP and Web Hooks
Build or inspect structured data	Objects or Result Objects blocks	Objects and Result Objects
Add focused JavaScript logic	Custom Code or Code Expression	Custom Code Blocks

Choose the family that matches the operation, not simply the type of Page Element involved. For example, a Button may need an event block to respond to a click, a Database block to retrieve information, and a Page Action block to display the result.

Toolbox Families and Reference Sections

The Page Flow toolbox groups blocks by editing purpose. Common families include:

• Flow, for startup and flow-related behavior.
• Page Content and Page Action, for reading, updating, and navigating page content.
• Input, Style/CSS, and Html/DOM, for inputs, styles, attributes, and element behavior.
• Widgets, Data Design, and Forms, for configured Page components and repeated content.
• Cloud Flow and Database, for server-side calls and permitted data operations.
• Logic, Text, Lists, Math, Objects, Functions, and Variables, for general programming operations.
• Advanced, for specialized behavior and custom logic.

The Programming Guide organizes the ioLoop-created blocks into reference sections such as General, Page Actions, Content, Forms, Database, Objects, and Result Objects. These documentation groups are not always identical to the names shown in the toolbox.

The Programming Guide focuses on ioLoop-created blocks. Standard Blockly programming blocks, including common logic and calculation blocks, are not individually documented there.

If a block is not listed under the reference category you first expect, use the toolbox Search area or the documentation search to find the block by its name or intended operation.

For adding, connecting, and arranging blocks on the canvas, see Editor Basics.

Flow, Events, and Startup

Begin by deciding when the behavior should run.

Requirement	Approach
Prepare content when the Page opens	Startup logic.
Run logic after a user selects a Button	An event associated with that Button.
Respond to a change in an input	A supported element event.
Perform logic after a widget action	The relevant widget event or action callback.
Reuse the same steps from several events	A function or procedure called by those event handlers.

The General Blocks reference includes blocks such as Flow Start and Event Action.

Flow Start is a recommended organizational starting point. It does not mean that every executable block must be connected beneath it. Event handlers and other supported flow constructs can define their own execution paths.

A typical interaction can be planned as:

User selects Search
  Event Action
    Read search input
    Retrieve matching records
    Update results area

This is a conceptual sequence, not a required set of block connections or a specific query implementation.

Logic and Reusable Functions

Use general programming blocks when the workflow needs to:

• Compare values or evaluate conditions.
• Choose between alternative paths.
• Repeat an operation for a list of items.
• Combine or format text.
• Calculate numbers, totals, or other values.
• Store intermediate values in variables.
• Group reusable operations into functions or procedures.

Keep the main event flow readable. For a larger Page, a short event handler that calls a clearly named function can be easier to maintain than a long sequence of unrelated steps.

For event timing and asynchronous execution, see Events and Startup.

Page Content and Page Actions

Use these blocks when the result of a workflow should change what the visitor sees or where the visitor goes.

Common operations include:

• Get or set the content of a Page Element.
• Navigate to another Page or URL.
• Show a confirmation popup.
• Close an open modal.
• Update content generated from Data Design.

For example, a View Details action may retrieve information and place it in a details area. A Continue action may navigate to another Page after the required work succeeds.

Some blocks work with ordinary Page Elements; others specifically target content generated from Data Design. Choose the appropriate block for the target you need to update.

References:

• Page Actions
• Content Blocks

Use Page Elements and Element Settings to configure the visual structure and available element properties. Use Page Flow to coordinate supported behavior at runtime.

Input, Style/CSS, and Html/DOM

Use input and element-oriented blocks when a workflow needs to read values from, or change the state of, visible elements.

Common operations include:

Requirement	Block approach
Read a text or other supported input	Input-value blocks.
Show validation feedback	Input-feedback blocks.
Enable or disable an element	Element state blocks.
Apply or change styling	Style/CSS blocks.
Read or set an HTML attribute	Element attribute blocks.
Target an element by its ID or another supported selector	Element or DOM Selector blocks.
Work with a toggle switch	Toggle state blocks.

For example, a Page may disable a Submit Button while required input is missing, then enable it when the user provides acceptable values.

Be clear about what is being changed. Updating a field's current value is different from updating the text or HTML content surrounding that field. Likewise, applying a CSS class is a presentation change; it does not grant or remove permission to perform a protected operation.

References:

• General Blocks
• Content Blocks
• Text and Content

Forms

Use Forms blocks when the workflow needs to open or coordinate an ioLoop Form, or when logic runs within a Form's own Page Flow.

Typical requirements include:

• Open a Form as a modal.
• Attach a Form to Data Table New or Edit actions.
• Provide edit data or shared context when opening a Form.
• Read the current Form data or original edit data.
• Check whether a Form is in edit mode.
• Lock, unlock, reset, or save a Form through supported operations.
• Handle Form lifecycle events and submission results.

For example, a Customers Page may use a Data Table action to open a Customer Form. The Form handles input and submission; the opening Page refreshes the table after a successful result.

A Form can receive shared context even when creating a new record. Edit data identifies and initializes an existing record, while current Form data represents the values entered in the Form. These are separate concepts.

Use the relevant blocks in the correct Page Flow: the opening Page's flow coordinates the modal and its result, while the Form's flow manages Form-specific behavior.

References:

• Forms Blocks
• Opening Forms as Modals
• Form Page Flow

Widgets

Use widget-related blocks when you need to coordinate a configured Widget with other Page behavior.

A Data Table Widget is a common example. Supported blocks can be used to:

• Refresh a Data Table.
• Load the next or previous page of records.
• Configure a custom query.
• Customize standard actions or add a custom action.
• Associate a Form with New or Edit workflows.

These operations appear in more than one Programming Guide category. For example, the Data Table paging blocks are documented under Page Actions, while refresh, custom query, and action customization blocks appear under General.

Choose a Widget block when you need to control the Widget's built-in behavior. Choose ordinary Page Content or Page Action blocks for changes to the surrounding Page.

Other Widgets may expose different controls or require configuration outside Page Flow. Do not assume that every Widget supports the same operations.

References:

• General Blocks
• Page Actions
• Forms Blocks
• Forms and Widgets
• Data Table Widget

Data Design

Use Data Design-related blocks when the Page needs to generate custom repeated content from data, or interact with elements within rendered instances.

Typical operations include:

• Generate content from a Data Design and a data object.
• Supply identifiers such as ID and optional ID2 for rendered instances.
• Place generated content into a target Page area.
• Read or update an element inside a specific rendered instance.
• Handle events from Buttons, inputs, toggles, or other supported elements in rendered content.

For example, a product catalog may use one Data Design to produce multiple product cards. A record-specific Details Button inside a card needs to be associated with the correct rendered item, rather than a single static element on the Page.

The Content from Data Design block generates content from a design and supplied data. Other Data Design-related blocks can target individual elements and interactions within the generated content.

Data Design blocks often work together with Database, Objects, and Page Content blocks:

Retrieve product records
  For each product
    Prepare placeholder values
    Generate content from Data Design
    Add content to the results area

This example illustrates the combination of block families; it is not a claim that one block automatically performs the entire operation.

References:

• Content Blocks
• Page Actions
• Data Design
• Rendering Data Design

Database

Use Database blocks when Page Flow needs to read or change Project data through supported client-side data operations.

Common operations include:

• Read records and query selected data.
• Add a new record.
• Update or delete a permitted record.
• Work with record identifiers.
• Read results from a dataset and move through dataset records.
• Use a named query where supported.

For example, a Page may retrieve permitted customer records, then display a summary or render them through Data Design.

Choose Database blocks when the operation is available through the Project's permitted client-side data interfaces. A custom Cloud Flow function is not required for every ordinary data read or update.

However, the browser is not a trusted authorization boundary. Database permissions must be configured appropriately. Use trusted Backend processing for protected business rules, private credentials, or operations that must be enforced independently of the browser.

References:

• Database Blocks
• Data and Cloud Flow
• Database

Cloud Flow and HTTP Requests

Use Cloud Flow when the browser needs trusted server-side processing rather than ordinary client-side coordination.

Examples include:

• Validate a protected business rule.
• Perform a server-side calculation that must be trusted.
• Use private credentials or call a protected Integration.
• Coordinate a multi-step Backend operation.
• Invoke a Cloud Flow web hook and handle its response.

The General reference includes Cloud Flow invocation blocks. The HTTP and Web Hooks reference includes HTTP request blocks and blocks for reading response data or errors.

Do not assume that an arbitrary external HTTP request is equivalent to invoking a configured Cloud Flow web hook. Choose the operation that matches the endpoint and the Project's integration and security requirements.

For example:

Visitor submits a booking request
  Read and validate browser input
  Invoke Cloud Flow for protected availability checks
    On success: show confirmation
    On failure: show an error or recovery message

Page Flow handles the visible interaction. Cloud Flow handles the trusted operation and returns a result that Page Flow can use.

References:

• General Blocks
• HTTP and Web Hooks
• Data and Cloud Flow
• Cloud Flow

Objects and Result Objects

Use Objects blocks when a workflow needs to group values into structured data rather than pass each value separately.

Common uses include:

• Build an object from several input values.
• Read or set properties of an object.
• Pass a structured object to a Form, Data Design, Database operation, or Cloud Flow.
• Inspect an object returned from another operation.

Use Result Objects blocks when the workflow needs a structured representation of an operation's result, including status, data, or error information.

For example, a custom request may need an object containing a customer identifier, selected service, and preferred date. A response may then need to be checked before updating the Page.

Do not assume that every operation returns the same object structure. Read the reference for the specific block and interpret only the values that operation actually provides.

References:

• Objects
• Result Objects

Custom Code and Code Expression

Use Custom Code or Code Expression when a focused JavaScript operation is clearer than assembling many blocks.

Block	Use it for
Custom Code	Execute JavaScript statements as part of a flow.
Code Expression	Evaluate a JavaScript expression and provide its result to another block.

For example, a Code Expression may calculate a value required by a nearby block. A Custom Code block may perform a small, specialized transformation that is difficult to express cleanly with standard blocks.

Keep the main workflow visible in Page Flow blocks. Avoid placing the entire Page behavior inside one large Custom Code block when regular event, data, and action blocks communicate the intent more clearly.

Use documented browser-side ioLoop APIs for Page Flow code. Do not assume that server-only APIs, private credentials, or internal runtime objects are available in the browser.

References:

• Custom Code Blocks
• Custom Code
• Client API

Choosing Blocks That Work Together

Most useful Page Flows combine a trigger, supporting data operations, and a visible result.

Consider a Page containing a Search input, a Search Button, and a results area:

1. Event: Use an event block to respond when the Search Button is selected.
2. Input: Use an input block to read the search text.
3. Decision: Use Logic blocks to handle an empty search value where needed.
4. Data: Use Database blocks to retrieve records available to the current user, or invoke Cloud Flow if trusted processing is required.
5. Presentation: Use Page Content blocks to show a message, Data Design blocks to display custom results, or a Data Table Widget when a standard table interface is appropriate.
6. Result handling: Show an empty state or error when the operation produces no matches or fails.

The correct combination depends on the Page design. You do not need every block family in every workflow.

Statement Blocks and Value Blocks

As you select blocks, distinguish between:

Kind	Role	Example use
Statement blocks	Perform work or define steps in a sequence.	Update content, send a request, or respond to an event.
Value blocks	Produce data that another block consumes.	Provide a text value, record ID, data object, or result.

A statement block may need one or more connected value blocks. Choose the required values first, then connect them to the operation they support.

The reference pages identify a block's accepted inputs and whether it produces an output. Use that information when two blocks do not connect as expected.

Asynchronous Operations

Some data reads, HTTP requests, Cloud Flow calls, and deferred operations finish after the initiating block has started its work.

When a block provides success, failure, or completion paths, place dependent actions in the appropriate path. For example, do not show Saved successfully before the save operation has actually completed.

Plan for:

• A successful response.
• An error or rejected operation.
• An empty result where relevant.
• A loading or temporarily disabled state when appropriate.

For more information, see Events and Startup and Previewing and Troubleshooting.

Finding and Verifying a Block

When you know the operation you need but not the block name:

1. Describe the behavior in simple terms, such as refresh a Data Table or read an input value.
2. Start in the most relevant toolbox family.
3. Use toolbox Search if the block is not immediately visible.
4. Add the block to the Page Flow canvas and inspect its inputs and options.
5. Right-click the block and choose Help when available.
6. Use the reference page to confirm the accepted input types, output, and behavior.
7. Connect it to the appropriate trigger, data, and result-handling blocks.
8. Save the Page Flow and test the complete interaction in Preview.

Do not choose a block solely because its name seems similar to the operation you need. Verify what data it accepts and whether it targets an ordinary Page Element, a rendered Data Design instance, a Form, or a Widget.

Good Practices

• Start from the intended behavior. Choose blocks according to the task, not merely the element type.
• Use the most specific supported block. Prefer built-in Page, Form, Widget, and Data Design operations where available.
• Keep event handlers focused. Use named functions or procedures for reusable steps.
• Use value blocks for data and statement blocks for actions. Confirm the required input and output types.
• Handle completion correctly. Place dependent actions inside the proper success or completion path.
• Keep frontend and Backend responsibilities separate. Use trusted processing for private credentials and protected rules.
• Read the reference when uncertain. A block's Help page is the authority for its supported inputs and behavior.
• Preview complete workflows. Test normal, empty, and failure outcomes rather than only the ideal path.

Common Mistakes

Avoid these patterns:

• Looking only in the reference section with the same name as a toolbox family and assuming a block does not exist elsewhere.
• Using a static Page Element block when the intended target is an element inside rendered Data Design content.
• Using a general Page action when a dedicated Form or Widget block handles the operation more clearly.
• Confusing an object or input value with a statement that performs an action.
• Assuming every asynchronous operation finishes before the next statement executes.
• Showing a success message before a Database or Cloud Flow operation succeeds.
• Performing protected authorization checks only in browser-side Page Flow.
• Writing a large Custom Code block when the logic would be clearer with supported visual blocks.
• Testing the block in isolation but not the complete Page or Form interaction.

Choosing the right blocks makes Page Flow easier to read, test, and maintain. Use the toolbox to find an operation, the Programming Guide to confirm its behavior, and Preview to verify how it works within the Page.

Related Topics

• Page Flow
• Editor Basics
• Events and Startup
• Forms and Widgets
• Data and Cloud Flow
• Custom Code
• Previewing and Troubleshooting
• Page Flow Blocks
• Client API