Previewing

Preview lets you run and test a saved Page or Form from inside the Project Editor before publishing the Project.

Use Preview to verify the complete user experience: layout, navigation, Page Flow, modal Forms, Widgets, Data Design, Project data operations, user access behavior, and interactions with Cloud Flow or connected services.

Preview runs the saved development version of the Page or Form. Previewing does not publish changes to the released application. During Preview, all built-in Database operations automatically use the Project's development database, rather than the published application's production database.

This page explains how to use Preview and what to test. For detailed diagnosis of Page Flow blocks, JavaScript, and runtime behavior, see Previewing and Troubleshooting.

What Preview Helps You Test

A Page can look correct in the Page Editor but behave differently when it runs. Preview lets you interact with the Page as a visitor would, rather than relying on its appearance on the editing canvas.

Common areas to verify include:

Area	What to Check
Layout and styling	Content arrangement, element visibility, spacing, text wrapping, and responsive behavior.
Navigation	Links, menus, Page URLs, and navigation triggered by Page Flow.
Page Flow	Startup behavior, events, Custom Code, and asynchronous results.
Forms	Modal opening, initial values, validation, submission, success, error, close, and cancel behavior.
Widgets	Data Tables, AI Agent Widgets, Payment Widgets, Chart Areas, and other supported components.
Data Design	Placeholder values, repeated content, empty results, and record-specific interactions.
Project data	Reads, permitted writes, queries, and refresh behavior against the development database used automatically by built-in Database operations during Preview.
Connected operations	Cloud Flow calls, Integrations, and the responses returned to the Page.
Access	Page behavior for Public visitors, Project Users, User Groups, and Admin, where applicable.

Preview is particularly useful after a change affects both visual content and interaction logic—for example, replacing a Button, changing a Page URL, adding a Data Table action, or changing a Form's fields.

Save Before Previewing

Preview uses the saved development state, not necessarily every change currently visible in an editor.

Before previewing a changed Page or Form:

1. Save the visual content and Element Settings in the Page Editor.
2. Save Page Settings if the Page URL, access configuration, or other Page-level properties changed.
3. Save Page Flow after changing visual blocks, Custom Code, or Code Expressions.
4. Save any referenced Forms, Data Designs, and other Project resources you have modified.
5. Open Preview and test the relevant behavior.

When Page Flow is saved, ioLoop generates the JavaScript used by the Page runtime. A block that exists only in unsaved Page Flow changes is not part of the saved behavior being previewed.

If visual changes are unsaved, the editor may warn that Preview will use the saved version. Save first if you want to test the latest changes.

Saving and previewing are separate steps. Saving retains development changes; Preview runs them for testing.

Opening Preview

To preview a Page or Form:

1. Open Pages & Forms in the Project Editor.
2. Open the item's actions and select Preview to use the current preview user context, which is Admin by default.
3. Interact with the Page or Form in the running preview.
4. Use Close to return to the Page Editor.

To select a particular preview user context before opening Preview:

1. Open the Page or Form with Edit.
2. Select the appropriate preview user context in the Page Editor toolbar.
3. Select Preview from the Page Editor toolbar.

In Preview, test the same sequence a visitor would follow: open the Page, select actions, enter values, navigate, and check what happens after an operation completes.

For a Form, direct Preview is useful for inspecting its layout and field behavior. To validate the complete modal workflow, also preview the Page that opens the Form.

Cloud Flow Development Test Runtime

Opening a Page or Form in Preview automatically starts the Cloud Flow development test runtime when it is not already running. You do not need to open Backend → Cloud Flow and choose Start Test before testing Cloud Flow called by a previewed Page or Form.

The development test runtime automatically stops two hours after it starts. Opening Preview again starts it when needed. Starting a new Preview does not restart an already-running runtime or extend its current two-hour period.

Use Start Test when testing Cloud Flow independently of Pages and Forms, such as when calling a development Web Hook URL directly or testing Background Task behavior. For runtime controls, Logs, and backend troubleshooting, see Testing and Logs.

Preview User Context

The Page Editor provides a preview user context selector beside the Preview action. Use it to test how the Page behaves for different kinds of Project visitors.

Available contexts can include:

Preview Context	What It Represents
Public	A visitor who is not signed in.
Any User	A signed-in Project User, without selecting a particular User Group.
Configured User Groups	A Project User associated with the selected User Group.
Admin	Administrator-level access context.

The contexts available for a particular Project depend on its user and access configuration.

Testing Access-Dependent Behavior

Use different contexts when the Page includes:

• Page access restrictions.
• Navigation intended for specific users or User Groups.
• Login Info or account-related elements.
• Data Table actions or other record operations.
• Database access rules.
• Page Flow behavior that depends on the current user.

For example, an administrative registration Page may be accessible to Admin but not to Public visitors. A customer portal may be available to signed-in users but display different data based on their permissions.

Test both the intended allowed context and relevant restricted contexts. Testing only as Admin can conceal access problems that ordinary Project Users would encounter.

The preview context helps test application behavior against the development environment; it does not replace Database permissions, Backend authorization, or verification of real user access in the published application. Built-in Database operations still use the development database regardless of which preview user context is selected. A hidden Button or menu item is not an access-control rule.

For access configuration, see Page Settings, Users, and User Groups.

Preview Toolbar

The Preview toolbar provides controls for moving through the running experience, changing its viewing size, inspecting runtime messages, and returning to editing.

Control	Purpose
Back	Moves backward through navigation history within Preview.
Forward	Moves forward through navigation history within Preview.
Desktop	Displays the Page at a desktop-oriented viewport size.
Tablet	Displays the Page at a tablet-oriented viewport size.
Mobile	Displays the Page at a mobile-oriented viewport size.
Console	Opens the Preview console to inspect messages and runtime errors.
Close	Exits Preview and returns to the Page Editor.

These controls let you test different aspects of a Page without reopening the visual editor for every check.

Testing Responsive Layouts

Use Desktop, Tablet, and Mobile to check how content responds to available width.

Pay particular attention to:

• Layout Rows and Columns that wrap or stack.
• Navigation menus and collapsible controls.
• Tables with several columns or long values.
• Repeated Cards and Data Design content.
• Images, headings, and text that may overflow.
• Buttons and touch targets that are difficult to use at narrow widths.
• Modal Forms that contain many fields or status messages.
• Fixed or positioned content that can obscure interactive elements.

For example, a Data Table may need less important columns hidden on mobile, while a card-based layout may need a different arrangement of repeated items.

Viewport previews help catch layout issues, but they are not a substitute for testing the published experience on actual devices when device-specific browser behavior matters.

For element-specific configuration, see Element Settings.

Previewing Navigation

Preview can follow navigation to other saved Project Pages. Use Back and Forward to review the path through the application.

When testing navigation:

1. Open the Page containing the navigation control.
2. Select the intended Link, Button, Menubar Item, or Page Flow action.
3. Confirm that the correct destination opens.
4. Test Back and Forward where the workflow requires them.
5. Repeat in a relevant preview user context when the destination is restricted.

Also consider what happens if:

• A Page URL has changed but an existing link still uses the old path.
• The destination Page is inactive or unavailable.
• The destination requires authentication or a particular User Group.
• A Page Flow operation must finish before navigation continues.

Use the Page URL configured in Page Settings, rather than assuming that the Page Name or Page/Form ID is its URL.

External links may follow browser-specific tab or window behavior. Test those destinations separately when needed.

Previewing Forms and Modal Workflows

Forms should be tested both as individual designs and as modal workflows opened from another Page.

First: Preview the Form

Open the Form in the Page Editor and use Preview to check:

• Field labels, input controls, and helper text.
• Required fields and supported input validation.
• Default values and relevant initial states.
• Submit controls and visible feedback.
• Success Status Area and Error Status Area content.
• Layout at desktop, tablet, and mobile widths.

Direct Form Preview is useful for inspecting the Form itself, but it may not reproduce information normally supplied by an opening Page.

Then: Preview the Opening Page

Open the Page that launches the modal and test the complete interaction:

1. Select the Button, Data Table action, or other control that opens the Form.
2. Confirm the intended Form appears.
3. Verify that it receives the correct edit data and/or shared context.
4. Check how its fields initialize.
5. Submit valid and invalid values.
6. Verify success, error, close, and cancel outcomes.
7. Check whether the opening Page refreshes or updates as intended.

Edit data identifies and initializes the record being edited. Shared context supplies additional workflow information and can be used by New, Edit, or Custom Forms. These are distinct from the current Form data entered by the visitor.

For example, an Add Registration Form can receive a selected Event ID as shared context while still opening in new-record mode. An Edit Registration Form can receive existing registration data as edit data and additional Event information as shared context.

Do not assume that closing a modal means submission succeeded. Confirm that the Form's operation completed successfully before treating the opening Page as updated. When a Table-Backed Form uses built-in Database operations during Preview, its record reads, creations, and updates affect the development database, not the published application's production database.

For the complete modal lifecycle, see Opening Forms as Modals and Form Page Flow.

Previewing Widgets and Data Design

Widgets and repeated content often depend on data or application state that is not visible in the Page Editor.

Component	What to Verify
Data Table Widget	Development records load through built-in Database operations, columns display correctly, toolbar controls work, and New/Edit/custom actions target the intended records.
AI Agent Widget	The configured Agent opens, the correct title and appearance are shown, and conversations behave as intended for the test context.
Payment Widgets	The expected provider connection and mode are selected, the amount is correct, and success/error paths are tested safely.
Chart Area	Supported chart behavior supplies output, and the surrounding layout leaves enough space for the visualization.
Login Info	Account-related presentation is appropriate for the chosen user context.
Data Design	Placeholders receive expected values, repeated content renders correctly, and item-specific actions use the intended record context.

Testing Data-Driven States

Where applicable, test:

• No matching records.
• A single record or rendered item.
• Many records or repeated items.
• Missing images or optional values.
• Long names and descriptions.
• Refresh and filtering behavior.
• Records that a user is not permitted to access.

For a Data Table, verify that visible data refreshes after an associated Form completes successfully when that refresh behavior has been configured.

For Data Design, confirm that a new search or filter does not leave outdated repeated items on the Page when the intended behavior is to replace them.

For detailed setup, see Widgets and Data Design.

Previewing Data and Connected Operations

Preview is an active runtime test. A Page may read or change data, invoke Cloud Flow, call an Integration, send notifications, or initiate a payment-related operation. Preview is not a simulation with no side effects.

Development Database During Preview

During Preview, ioLoop automatically directs all built-in Database operations to the Project's development database.

This applies to built-in operations that read or modify Project data while you test Pages, Forms, Page Flow, and data-backed Widgets. For example:

Built-in Database Operation	Behavior During Preview
Read or query records	Retrieves records from the development database.
Create records	Adds records to the development database.
Update records	Changes records in the development database.
Delete records	Removes records from the development database.
Table-Backed Form operations	Built-in record loading and submission work with development records.
Data Table and other data-backed Widget operations	Built-in data loading and record actions work with development records.

No additional configuration is needed to select the development database for built-in Database operations in Preview. Those operations do not read from or write to the published application's production database.

This separation allows you to test record workflows without changing production records. However, writes and deletes performed during Preview do change the development database, so use appropriate test records and verify the results.

For example, previewing an event-registration Page with a Table-Backed Form can create a new registration in the development database. You can then use Preview to test editing or displaying that registration without adding it to the production database.

Cloud Flow and External Services

The automatic development-database routing described above applies to built-in Database operations during Preview. Do not assume that every operation triggered from a previewed Page is automatically redirected to a test environment.

In particular, review the behavior of:

• Cloud Flow, especially when it calls external systems or performs custom processing.
• Custom JavaScript, especially if it makes direct requests or uses explicitly configured connections.
• Integrations and external services, which may have their own test and live modes.
• Payment provider connections, which must be checked before running a payment test.
• Email delivery and notifications, which may contact real recipients.

A Page can use the development database for its built-in Database operations while an external provider connection still targets a live service. Check each connected operation independently; do not infer its target environment from Preview alone.

Testing Operations With Side Effects

Before testing an operation that changes data or contacts an external service:

1. Confirm that built-in Database operations will affect the development database.
2. Identify any Cloud Flow, custom-code, or Integration operations in the same workflow and verify their actual targets.
3. Select the intended preview user context and use appropriate development records.
4. Use provider test connections or test modes where available and appropriate.
5. Confirm the input values before initiating an operation that has side effects.
6. Verify the outcome, including development records created or changed and any external responses.
7. Test how the Page handles failure or an unavailable service.

For example, a registration workflow may store a development registration record through a built-in Database operation and also send an email through a configured delivery service. The Database record uses the development database automatically; the email behavior depends on the delivery connection and workflow configuration.

Access and Authorization

Preview can help test permitted and denied operations, but it does not establish security by itself.

• Page access controls determine who can open restricted Pages.
• Database access rules govern permitted data operations, including built-in operations against the development database during Preview.
• Trusted Cloud Flow or other Backend processing should enforce protected business rules and sensitive authorization decisions.
• Page Flow executes in the browser and should not be the only enforcement point for protected operations.

Testing a permitted operation against development records does not establish that the published application is configured correctly for its real users and production data. Verify important access paths after publishing.

For more detail, see Data and Cloud Flow.

Preview Console

The Console control opens a development view for inspecting messages and runtime errors while the Page is running in Preview.

Open it when:

• A Button or event appears to do nothing.
• Startup behavior does not produce the expected result.
• Custom Code reports an error or writes diagnostic messages.
• A Database or Cloud Flow operation fails.
• A Widget or rendered design does not update.
• A modal Form opens but cannot complete its workflow.

A practical diagnosis sequence is:

1. Reproduce the behavior in Preview.
2. Open Console and inspect relevant messages or errors.
3. Identify whether the problem concerns an event, element reference, data operation, Backend call, or Custom Code.
4. Return to the relevant Page Editor or Page Flow configuration.
5. Save the correction and preview again.

The Preview console is a development tool. Visitors should still see useful confirmation or error messages through the Page or Form itself.

Detailed block-level diagnosis belongs in Previewing and Troubleshooting.

Example: Testing a Customer Management Page

Consider an administrative Page containing a Customers Data Table and a Table-Backed Customer Form.

The Page supports creating customers, editing customers, and refreshing the table after a successful save.

A useful Preview sequence is:

1. Save the components. Save the Customers Page, the Customer Form, and their Page Flow changes. Built-in Database operations in Preview will use the development database.
2. Check access. Preview using Admin and a relevant non-admin context. Confirm that each context can perform only intended operations.
3. Load the table. Verify that permitted customer records appear and that the table layout remains usable at mobile width.
4. Create a development record. Select New, confirm the Customer Form opens in new-record mode, enter test values, and submit. Verify that the new customer was created in the development database.
5. Check the result. Confirm that the operation succeeded and that the table reflects the new record after the configured refresh.
6. Edit the development record. Select Edit for the test customer, verify that its existing values appear, change a value, and save. Confirm that the development record was updated.
7. Test validation. Repeat with a missing required field or unsupported value and confirm that the Form displays helpful feedback.
8. Test cancellation. Open the Form and close it without saving. Confirm that no unintended record changes occur.
9. Test failure. Where safely reproducible, verify how the Page responds to an access denial or unsuccessful data operation.
10. Review runtime messages. Use the Preview console if an action behaves unexpectedly.

This example demonstrates why inspecting the Page's visual design alone is not enough. The complete experience includes the opening action, modal context, data operation, feedback, and the surrounding Page's response. Because built-in Database operations target the development database in Preview, these tests do not create or update production customer records.

Save, Preview, Publish Project, and Launch Project

These actions serve different purposes in the development and release lifecycle.

Action	Purpose
Save	Stores changes in the Project's development state.
Preview	Tests the saved development version inside the Project Editor. Built-in Database operations automatically target the development database.
Publish Project	Releases the current development state to the published application.
Launch Project	Opens the published application for verification.

A successful Preview does not publish changes. Launch Project does not publish pending changes either; it opens the currently published application.

After testing and saving the relevant development changes:

1. Use Publish Project when the application is ready for release.
2. Use Launch Project to open the released application.
3. Check the actual published URLs, access behavior, and connected operations that matter to the release.

The published application can differ from Preview when the published version, authentication context, external provider configuration, or other environment-dependent behavior differs. In particular, Preview tests built-in Database operations against development data, not the production records used by the published application. A record created during Preview should not be assumed to exist in production. Verify important release paths after publishing.

For release steps, see Publish Project.

Preview Checklist

Use this checklist for the parts of the Page or Form that apply to your Project.

Area	Check Before Publishing
Saved changes	Latest Page, Form, Page Flow, Widget, and Data Design changes are saved.
Initial state	The Page loads with the expected startup content and behavior.
Navigation	Links, menus, and Page Flow navigation reach the correct destinations.
Interactions	Buttons and other controls perform their intended actions.
Forms	New, Edit, validation, success, failure, and cancel paths work correctly.
Widgets	Data Tables and other configured Widgets load and respond correctly.
Data Design	Repeated content handles normal, empty, and missing-value cases.
Development database	Built-in Database reads and writes use development records; created, updated, and deleted test records have the expected result.
Connected operations	Cloud Flow, custom-code, and Integration calls return expected outcomes, with external service modes and destinations verified separately.
Access	Public, Project User, User Group, and Admin behavior is tested as applicable.
Responsive design	Desktop, tablet, and mobile previews remain usable.
Runtime errors	Relevant console messages are reviewed and problems addressed.
Release	The published experience is verified with Launch Project after publishing.

Not every Page needs every test. Focus on the real workflows and dependencies of the Page being released.

Good Practices

• Save before testing. Preview the version you intend to release.
• Test complete visitor paths. Verify the result of an action, not only that its first step starts.
• Use representative user contexts. Include restricted and least-privileged contexts where relevant.
• Test responsive interactions. Check that controls remain usable as well as visually correct.
• Use realistic content. Include empty results, long values, and missing optional data.
• Use development records deliberately. Built-in Database operations automatically use the development database during Preview; they can still change or delete development data.
• Treat external operations separately. Check Cloud Flow, custom-code, Integrations, and provider test/live modes rather than assuming Preview redirects every operation.
• Check both outcomes. Test success and failure behavior for important operations.
• Use the Console to diagnose runtime issues. Provide proper user-facing messages in the Page itself.
• Verify after publishing. Preview and Launch Project test different application states.

Common Mistakes

Avoid these patterns:

• Previewing without saving the latest Page or Page Flow changes.
• Assuming that Preview automatically publishes the Page.
• Testing only the Admin context when regular users will use the feature.
• Testing only desktop layout and overlooking mobile interaction problems.
• Inspecting a Form directly without testing how the opening Page passes edit data or shared context.
• Treating the modal closing as proof that a submission succeeded.
• Testing only successful submissions and ignoring validation or Backend failures.
• Assuming Preview cannot modify data: built-in Database operations can change the development database.
• Assuming built-in Database operations in Preview read or write production records.
• Assuming external services are automatically switched to test mode because the Page is in Preview.
• Treating hidden content or browser-side validation as authorization.
• Ignoring relevant runtime errors shown in the Preview console.
• Publishing without checking the released application afterward.

Preview is most useful when it is treated as a complete development test: save the Page, interact with it in realistic user contexts, verify built-in Database behavior against development records, check connected-service side effects separately, then publish and validate the released application.

Related Topics

• Pages & Forms
• Page Editor
• Page Settings
• Element Settings
• Forms
• Opening Forms as Modals
• Form Page Flow
• Page Flow
• Previewing and Troubleshooting
• Cloud Flow Testing and Logs
• Widgets
• Data Design
• Publish Project
• Users
• User Groups