Development and Production Data

ioLoop separates development data from production data so Creators can build and test a Project without automatically changing the records used by the published application.

The two environments use the Project's table definitions at their respective development or published versions, but they maintain separate records. Understanding what happens during Preview, Publish Project, and direct record editing is important when introducing new features or changing existing tables.

Development and Production at a Glance

Area	Development	Production
Purpose	Build, preview, and test application workflows.	Run the published application with live records.
Table data view	Data in the table's action menu.	Production Data, where available under the subscription plan.
Records	Test and development records.	Records used by the published application.
Built-in Database operations	Automatically target development data during Preview.	Target production data in the published application.
Table structure	Changes take effect in development as they are made.	Published changes take effect when the Project is published.

Use development records to try features, reproduce errors, and test unusual cases. Treat production records as live application data. Editing or deleting them can affect real users and published workflows.

For the steps to browse, search, create, edit, or delete records, see Table Data.

Database Operations During Preview

During Preview, all built-in Database operations automatically use the Project's development database. This includes built-in reads, creates, updates, and deletes, including operations used by supported Forms, Widgets, and Page Flow.

No separate Database environment setting is required for these operations during Preview.

For example, when testing a registration Form in Preview:

1. Open the event Page in Preview.
2. Submit a test registration using the Form's configured Database operation.
3. Open Backend → Database → Registrations → Data.
4. Verify that the new registration appears among development records.
5. The submission does not create a production registration through that built-in Database operation.

Preview is still an active test environment: its built-in Database writes can change or delete development records.

External services need separate consideration. Cloud Flow, custom code, and Integrations may perform operations outside the Project's built-in Database environment. When they use external services, private connections, or other side effects, verify their configured behavior rather than assuming Preview automatically redirects those external operations to test systems.

For the full Preview workflow, see Previewing.

What Happens When You Publish

Publishing releases the Project's saved development configuration to the published application. Publishing table definitions and copying table records are different operations.

Change	Effect in Development	Effect in Production
Add a table field	The field is added to existing development records immediately, using a default value based on its type.	Existing production records receive the new field when the change is published.
Remove a table field	The field is removed from existing development records immediately.	The field is removed from production records when the change is published.
Change a field type	Existing development values are converted immediately; conversion may be lossy or may produce type defaults.	Existing production values are converted when the change is published.
Create, edit, or delete a development record	Changes development data.	Does not, by itself, change production records.
Publish Project	Releases the saved Project configuration.	Applies the published structure and configuration; copies development records only into corresponding production tables that are empty.
Clone a table	Creates a separate table with copied fields, non-system named queries, and existing access configuration, but no copied records.	Does not clone the original table's production records.

Changes to table structure can therefore affect existing records, not just newly created ones. Before publishing a field removal or another significant schema change, review the production impact and any Pages, Forms, queries, Cloud Flows, or custom code that depend on the affected fields.

For table changes and dependencies, see Managing Tables and Table Fields.

Copying Development Records to Production

Development records are not routinely copied into production when publishing.

When a corresponding production table is empty, publishing copies that table's development records into it. The rule is evaluated separately for each table.

If a production table already contains records, publishing does not add, merge, or overwrite its records with development records. Plan the release of a populated table as a configuration and structure change while preserving the distinction between the two data environments.

Review development records before the first production use of a table. Sample or test records left in development can become production records when the corresponding production table is empty at publish time.

This separation allows a Project to have sample customers, registrations, or orders in development while populated production tables contain entirely different records.

Example: Adding a Registration Status Field

Suppose an event application already has a Registrations table in production. You want to add a CheckInStatus field and display it on an administrator Page.

1. Change the table definition. Add CheckInStatus in development. Existing development records receive the new field with its type-based default.
2. Update the application. Configure the relevant Form, Data Table Widget, named query, or Page Flow to use the new field.
3. Test in Preview. Use development registrations to verify the display and update workflows. Built-in Database operations work on development records.
4. Review production impact. Consider the default values that existing production registrations will receive, as well as any workflows that depend on the field.
5. Publish Project. The schema change is applied to production records as part of the publishing process.
6. Verify the published experience. Check that the new field and affected workflows operate correctly with actual production records.

The development registrations used in testing are not automatically merged into the live registration records.

Accessing Production Data

Where the subscription plan provides the Production Data action, Creators can inspect and manage records in the live environment from the Project Editor.

Before making a direct production edit:

• Confirm the table and that the view is marked Production Data.
• Confirm the intended record and the impact of the change.
• Consider related records, file fields, and published workflows.
• Avoid using production records for experiments that can be performed in development.

A Creator's ability to inspect data in the editor is distinct from a Project User's permissions at runtime. Continue to enforce appropriate Table Access rules and trusted authorization checks.

Good Practices

• Use Preview for development testing. Its built-in Database operations target development records automatically.
• Keep development data representative. Include enough variation to reveal problems before publishing.
• Review schema changes before release. Added, removed, or retyped fields affect existing records at different stages in development and production.
• Do not assume record synchronization. Development and production records remain separate unless a supported copy operation is explicitly used under its constraints.
• Treat Production Data as live administration. Check the environment and intended changes before editing.
• Verify external side effects independently. Integrations and custom external operations may not be isolated simply because the Page is in Preview.
• Verify after publishing. Development success does not guarantee identical results with production data.

Common Mistakes

Avoid these patterns:

• Assuming Preview's built-in Database operations modify production records.
• Assuming every Cloud Flow or external Integration call automatically uses a test service during Preview.
• Assuming publishing copies development records into an existing production database.
• Treating a table clone as a copy or backup of table records.
• Removing a field without considering the effect on existing records and dependent workflows.
• Testing only with development data that does not represent the published application's actual conditions.
• Editing Production Data when the intention was to modify development test records.

The central distinction is simple: Preview runs built-in Database operations against development data; the published Project uses production data; and publishing schema changes does not mean copying development records.

Related Topics

• Database
• Table Data
• Managing Tables
• Table Fields
• Table Access
• Previewing
• Publish Project
• Cloud Flow Testing and Logs