ioLoop Docs

Appearance

Checkpoints ​

Checkpoints preserve meaningful points in a Project's development configuration. Use them before significant changes, when completing a stable milestone, or when you may need to return the development Project to an earlier configuration.

A checkpoint is not a complete backup of the application. It does not preserve Database records or uploaded media, and it does not replace external backups, credential management, or release testing.

Opening Checkpoints ​

To open Checkpoints:

  1. Open the Project in the Project Editor.
  2. Select Settings.
  3. Select Checkpoints.

The list shows each checkpoint's message and creation date. Select a checkpoint to view its changes or begin a rollback.

When to Create a Checkpoint ​

Create a checkpoint at points that would be useful to recognize later, such as:

  • Before restructuring Pages or layouts.
  • Before changing Database structure.
  • Before replacing Connections or Connection Profiles.
  • Before a substantial Cloud Flow or AI Agent change.
  • Before changing shared frontend Code or Project Settings.
  • After completing and testing a stable milestone.
  • Immediately before rolling back to an older checkpoint when the current Project contains newer changes.

Use a message that describes the Project state or completed outcome. Customer portal before billing changes is more useful than Backup or Latest.

Creating a Checkpoint ​

To create a checkpoint:

  1. Open Settings → Checkpoints.
  2. Select Create Checkpoint.
  3. Review or replace the suggested message.
  4. Enter a concise description of the Project state.
  5. Select Create Checkpoint.

If the Project has no changes since the latest checkpoint, no new checkpoint is created.

Creating a checkpoint does not publish the Project. It records the supported development configuration at that point.

Viewing Checkpoint Changes ​

Select a checkpoint and choose View Changes to inspect the changes associated with it.

The summary groups changes into user-facing Project areas, such as:

  • Project Settings.
  • Pages and Forms.
  • Page Slices and Page Flow logic.
  • Frontend Code files.
  • Database structure.
  • Connections and Connection Profiles.
  • Cloud Flow and AI Agent configuration.
  • User Groups.

The summary identifies additions, updates, and removals where applicable. It is intended to help evaluate a checkpoint; it is not a line-by-line source comparison.

Project User changes are not shown in checkpoint reports and are not restored by rollback.

Rolling Back a Checkpoint ​

Rollback changes the development Project to match the selected checkpoint for the supported configuration.

Before rollback, the current Project must match the latest checkpoint. If it contains changes that are not in the latest checkpoint, create a new checkpoint first. This preserves a return point and prevents unrecorded Project configuration from being silently replaced.

To roll back:

  1. Save any editor work that must be retained.
  2. Create a checkpoint for the current Project if prompted or if recent work should remain recoverable.
  3. Select the target checkpoint.
  4. Choose Rollback.
  5. Review the rollback summary carefully.
  6. Confirm the rollback.
  7. Reopen and test the affected Project areas.
  8. Publish the Project when the restored configuration must replace the current published version.
  9. Verify the published application after publishing.

Rollback does not automatically make the restored development configuration live. Until a successful publish, the published Project generally continues to use its current published version.

What Checkpoints Cover ​

Checkpoints are intended to restore supported Project configuration, including applicable settings and definitions for areas such as:

  • Project Settings.
  • Pages, Forms, layouts, and Page Flow.
  • Frontend Code files.
  • Database table structure and related configuration.
  • Connections and Connection Profiles.
  • Cloud Flow and AI Agent configuration.
  • User Group names.

Some restored components require republishing before they affect the published Project. This includes restored Connection and Connection Profile configuration.

After rollback, inspect every area shown in the rollback summary rather than assuming that a successful rollback guarantees a working application.

What Checkpoints Do Not Restore ​

Checkpoints do not restore:

  • Project Users.
  • Database records.
  • Uploaded media files.
  • External service data.
  • Credentials or authorization state maintained outside the Project.
  • Changes made directly in an external provider.
  • A user's active browser session or actions performed through the application.

If these items require backup or recovery, use a process designed for that data or external system.

Database Effects ​

Checkpoints preserve Database structure, not Database records. However, rolling back structure can still affect existing data.

For example, rollback can restore an earlier structure that:

  • Removes a table created after the checkpoint.
  • Removes fields added after the checkpoint.
  • Restores earlier field definitions.
  • Changes queries or table access configuration.

These changes can remove data or require values to be converted. A checkpoint therefore must not be treated as a safe record-level backup.

Before rolling back Database structure:

  1. Identify every affected table and field in the rollback summary.
  2. Export or otherwise back up important development records separately.
  3. Review Forms, Widgets, Page Flow, Cloud Flow, AI Agents, queries, and custom code that depend on the changed structure.
  4. Perform the rollback.
  5. Inspect representative development records.
  6. Test the affected workflows in Preview.
  7. Review production-data consequences before publishing.

Publishing a rolled-back Database structure can affect production records. For details about the separation between development and production data, see Development and Production Data.

Media Effects ​

Uploaded media files are not restored by checkpoint rollback.

A restored Page or setting may refer to a media item that was deleted after the checkpoint. Rolling back the Page does not recreate the missing file, so images, downloads, or other media references can remain broken.

Before deleting important media or performing a rollback:

  • Keep the original file in an appropriate external location.
  • Identify Pages, layouts, metadata, and Code that refer to it.
  • Re-upload missing files when necessary.
  • Verify media URLs in Preview and after publishing.

Connections and External Services ​

Rollback can restore earlier Connection and Connection Profile configuration in the development Project. Republish before relying on that restored configuration in the published application.

A checkpoint cannot reverse actions already performed in an external service. For example, rollback does not undo a payment, remove an email that was sent, delete a calendar event, revoke an external access token, or reverse data written to an external API.

After restoring integration configuration:

  • Confirm that the referenced Profile is still authorized.
  • Check provider scopes and account selection.
  • Test the Connection in the intended environment.
  • Review access rules.
  • Republish and verify the published workflow.

Users and User Groups ​

User Group names are part of the supported Project configuration and can be restored. Project Users and their membership are not restored.

This means rollback can change the labels shown for groups without returning the user list to its earlier state. Review Users and group membership after rollback, especially when a group was renamed or repurposed between checkpoints.

Rollback and Publishing ​

Use rollback and publishing as separate stages:

  1. Rollback restores supported development configuration.
  2. Preview and test validates the restored development Project.
  3. Publish Project releases the restored configuration.
  4. Verify confirms the published application, authentication, data behavior, and integrations.

Do not publish immediately after a substantial rollback without reviewing its Database, access, integration, and media consequences.

Recovery Checklist ​

After rollback, verify:

  • The intended Starting Page and Project URL settings.
  • Important Pages, Forms, layouts, and navigation.
  • Project-level and Page-level Code.
  • Database tables, fields, queries, and representative records.
  • Project Users, User Groups, and access rules.
  • Connections, Profiles, Cloud Flow modules, and Web Hooks.
  • AI Agents, Knowledge Sources, and permitted functions.
  • Media references and downloadable files.
  • Preview behavior for public and signed-in users.
  • The published application after republishing.

Good Practices ​

  • Create checkpoints before high-impact or difficult-to-reverse configuration changes.
  • Use messages that describe a stable milestone or the change about to begin.
  • Create a checkpoint of the current state before rolling back.
  • Back up important Database records and media separately.
  • Review the rollback summary before confirming.
  • Test development behavior before republishing.
  • Verify external Connections and credentials after rollback.
  • Keep a record of why a rollback was performed and what was verified afterward.

Common Mistakes ​

Avoid these patterns:

  • Treating a checkpoint as a backup of Database records.
  • Expecting deleted media to return after rollback.
  • Expecting Project Users or their membership to be restored.
  • Assuming rollback reverses actions in an external service.
  • Rolling back Database structure without protecting important records.
  • Forgetting to republish restored Connections or Connection Profiles.
  • Publishing a rollback without testing Pages, permissions, data, and integrations.
  • Using vague checkpoint messages that do not identify the saved state.