Managing Tables

Tables define the main data structures in an ioLoop Project. Each table stores records for one application concept, such as customers, registrations, orders, tasks, or documents.

Use Backend → Database to create, edit, clone, and delete tables. Table definitions are shared by the Project capabilities that use them, so a structural change can affect Forms, Data Table Widgets, Data Design, Page Flow, Cloud Flow, AI Agents, and custom code using the ioLoop APIs.

This page explains how to manage a table throughout its lifecycle. For field types and settings, permissions, queries, and record-level operations, use the dedicated Database guides linked below.

What a Table Represents

A table groups records that describe the same kind of information.

Example Table	Purpose
Customers	Stores customer information.
Registrations	Stores registrations associated with events.
Orders	Stores order or purchase records.
SupportTickets	Stores support requests and their status.
Documents	Stores records associated with uploaded files.

For example, an event application might have separate Events and Registrations tables. An event has its own details, while a registration represents an attendee's participation in an event.

Keeping distinct application concepts in separate tables makes their fields, queries, access rules, and workflows easier to understand and maintain. It does not mean every new Page or Form needs its own table; several interfaces can use the same table.

Table Lifecycle at a Glance

Task	When to Use It	What to Check
Create	The Project needs a new type of stored record.	Name, fields, access rules, and initial workflows.
Edit	An existing record structure needs to evolve.	References to existing fields and compatibility with stored records.
Access (Security)	Runtime users and groups need controlled access to table operations.	Read, add, modify, and delete permissions.
Queries	Several components need the same record retrieval pattern.	Search Criteria, Field Selection, Data Joins, Sorting Order, and query inputs.
Data	Development records need to be created, inspected, or corrected.	Test records, field values, paging, and workflow results.
Production Data	Live records need to be inspected or corrected where supported by the subscription plan.	Intended table, production impact, and record safety.
Clone	A similar table structure is needed for a different purpose or experiment.	What was copied and which settings or references still need attention.
Delete	A table is no longer needed.	Dependent components, existing records, and published workflows.

A table may be referenced from multiple parts of the Project. Before making significant changes, identify those dependencies rather than treating the table as an isolated editor item.

Table Actions in the Editor

In Backend → Database, each table has an action menu for the main table operations.

Action	Use It For
Edit	Opening the table definition to review or change its fields and settings.
Access (Security)	Managing which Project Users and User Groups can read, add, modify, or delete records through supported runtime features.
Queries	Opening the table's named queries.
Data	Opening the development record browser and record editor.
Production Data	Opening production records where supported by the subscription plan.
Clone	Creating a new table based on an existing table.
Delete	Removing a table after dependencies have been reviewed.

The Data and Production Data actions open the record editor for the selected table. From there, Creators can search, refresh, download the displayed data, add records, and select a row to edit an existing record. The current Project Editor view loads all records rather than setting a page size, so its paging buttons are disabled. These actions are useful for table verification, but they do not replace testing the actual Form, Widget, Page Flow, Cloud Flow, AI Agent, or custom code path that users will rely on.

For record-level guidance, see Table Data.

Creating a Table

Create a table when the application needs to store a new kind of record.

Typical Workflow

1. Open the Project in the Project Editor.
2. Go to Backend → Database.
3. Select New Table.
4. Enter a clear, meaningful table name.
5. Configure the fields required for the first version of the workflow.
6. Save the table definition.
7. Use Access (Security) to configure the intended table access rules.
8. Add named queries if multiple components will use the same retrieval pattern.
9. Use Data to create representative development records.
10. Test the table through the Pages, Forms, Page Flow, or Cloud Flow operations that will use it.

Start with the actual user workflow. For example, a registration system may initially need an event reference, attendee name, contact email, registration status, and registration date. Additional fields can be introduced as the requirements become clearer.

Not every field needs to appear in a Form. Some values may be maintained by the application, set by Page Flow, or assigned through trusted Backend processing.

Before Connecting the Table to the Interface

Check that:

• The table name identifies the intended record type.
• The field definitions support the values the workflow needs.
• Fields with User Input enabled can be supplied by the intended create and edit workflows, while system-supplied fields have appropriate defaults or automatic ID settings.
• Access rules permit the intended operations without exposing unrelated data.
• Any named queries have been tested with representative records.
• Server-enforced business rules are implemented where necessary.

For implementation details, see Table Fields, Table Access, and Queries.

Naming Tables

Choose names based on the information being stored, not the first Page that happens to display it.

Examples of clear names:

Customers
Orders
EventRegistrations
SupportTickets
ProductCatalog

A good table name is recognizable, descriptive, and stable enough for long-term use.

Avoid temporary or presentation-based names such as NewPageData, Table2, or BlueCards. A table may be used by several Pages, Forms, Widgets, AI Agents, and Backend workflows over time.

Table Names and References

Table names may be referenced by named queries, visual programming blocks, JavaScript, Cloud Flow, and other Project configuration.

Before changing an established name or replacing a table with another one, review the components that use it. A label used in the Project Editor is not necessarily interchangeable with the table identifier expected by application logic.

Use the actual table names and identifiers exposed by the relevant editor and API. Do not assume that changing a visible label updates every reference elsewhere in the Project.

Editing a Table

Edit a table when its structure or configuration must change to support the application.

Common changes include:

• Adding fields needed by an expanded workflow.
• Adjusting field labels or supported settings.
• Reviewing User Input, default, and automatic ID configuration.
• Adding a field that holds a file-associated value.
• Revising access rules.
• Updating named queries that use the table.

A new field is often easier to introduce than a change to an existing field that many components already use. Treat changes to field types, User Input, automatic values, and other shared behavior carefully. The generated Field ID is read-only in the field editor; changing the Field Title does not rename it.

Reviewing an Existing Table Before Editing

Before making a significant change:

1. Identify what the table currently represents and where it is used.
2. Review the affected fields and any existing records that depend on their structure.
3. Check Forms, Widgets, Data Design, and named queries that reference those fields.
4. Check Page Flow, Cloud Flow, custom frontend code, Server API usage, and AI Agent configurations that use the table.
5. Decide how existing and newly created records should behave after the change.
6. Make the intended change, then test the relevant workflows with development data.
7. Review the publishing impact before releasing changes used by the published application.

Structural Changes and Existing Records

A field change can affect both application code and stored information.

For example, turning off User Input changes who supplies a field's value. Changing a field's meaning or type may make existing values unsuitable for the new workflow. Replacing or removing a field may break a Form or query that still expects it.

When a table structure is edited, existing development records are updated immediately to match the new structure:

• If a field is added, existing development records receive the new field with a default value based on the field type.
• If a field is removed, that field is removed from existing development records.
• If a field's top-level type changes, existing development values are converted to the new type. Conversion can be lossy or can produce a type default.

Production records are not changed at the time of the editor-side structure change. When the Project is published, the same structural update is applied to the production database.

Before making such changes, plan any necessary data preparation and updates to dependent components. Do not assume the editor will rewrite every Page Flow or Cloud Flow reference, or that existing values will still mean the same thing after a structural change.

For detailed field guidance, see Table Fields.

Managing Records for a Table

Use Data from a table's action menu when you need to inspect or prepare development records for testing.

The table data editor uses the selected table's field definition to show a record list and generate the add/edit record panel. Selecting New opens an add-record panel. Selecting an existing row opens the row action menu, where Edit opens the record editor for that record.

Use this record editor to:

• Create representative development records.
• Correct test records while building a workflow.
• Inspect values saved by Forms, Widgets, Page Flow, Cloud Flow, AI Agents, or custom code.
• Confirm file-oriented fields and other field values were stored as expected.
• Delete development records that are no longer useful.

Direct record edits are a development convenience. They may bypass parts of the user-facing workflow, so they should be followed by testing through the actual feature that creates or updates the record.

Use Production Data only when you intentionally need to inspect or correct live records and the option is supported by the subscription plan. The production record editor is marked as production in the table data view, and changes there affect the published Project's production data environment.

Cloning a Table

Use Clone when another table should start from the same fields, named queries, and access configuration as an existing table.

Cloning copies the table fields, non-system named queries, and the table's access record when one exists. It does not copy the table's records. Any records needed for development testing or production use must be created separately.

Cloning can be useful when:

• A new business workflow resembles an existing one but needs its own table.
• You want a separate structure to experiment with while leaving the original table in use.
• A table's fields provide a useful starting point for a related application concept.

After Cloning

Treat the new table as a separate application resource that needs review.

1. Give the cloned table a distinct, meaningful name.
2. Review its fields and update anything that is specific to the new purpose.
3. Review the copied access settings and configure the intended permissions.
4. Review and adjust the copied non-system named queries.
5. Determine whether any records need to be created or prepared for testing.
6. Update the Pages, Forms, Widgets, Page Flow, Cloud Flow, and AI Agent configurations that should use the new table.
7. Test the new workflow before making it available to users.

Cloning does not copy table data. It also does not copy the hidden system queries as ordinary named queries. Review the cloned fields, access settings, named queries, and test data before relying on the new table.

Cloning a table also does not automatically repoint existing application components to the new table.

Cloning Is Not a Backup or Rollback Plan

A cloned structure may help with experimentation, but it should not be treated as a guaranteed backup of records or a reversible database migration. If an existing table contains important data, plan changes and recovery separately using the supported Project capabilities.

Deleting a Table

Delete a table only when its purpose has ended and the Project no longer depends on it.

A table may still be required even when it is no longer visible in a Page. For example, a Cloud Flow workflow, AI Agent, scheduled backend task, or integration may still read or update it.

Dependency Checklist

Before deleting, review the following potential dependencies:

Project Area	What to Check
Forms	Table-backed Forms and their field connections.
Data Table Widgets	Record sources, columns, and New/Edit workflows.
Data Design	Queries and Page Flow operations supplying rendered records.
Page Flow and custom frontend code	Database operations, named queries, and table identifiers.
Cloud Flow	Backend reads, writes, Web Hooks, and background tasks.
AI Agents	Table Knowledge Sources and function workflows.
Integrations and external callers	Operations that expect the table or its data to remain available.
Published application	User-facing workflows that rely on the table.

Also determine whether the existing records need to be preserved for operational, reporting, or other legitimate requirements.

Safe Deletion Workflow

1. Confirm that the table is no longer required.
2. Review dependent components and existing records.
3. Remove or update references in the affected Project resources.
4. Test the revised workflows before removing the table.
5. Use the table's Delete action only after confirming the intended impact.
6. Review affected Pages, Cloud Flow workflows, AI Agents, and published behavior as part of the subsequent release process.

Deleting a table can make record-dependent functionality fail. Do not assume deletion is reversible or that references elsewhere will be updated automatically.

If there is uncertainty about whether a table is still used, leaving it unused while investigating dependencies is safer than deleting it immediately.

Tables, Development Data, and Publishing

Development and production records serve different purposes.

During Preview, ioLoop automatically directs built-in Database operations to the Project's development database. This means test reads and writes through those operations use development records rather than production records.

Use development records to verify the effect of table changes on new, edit, query, and access workflows. Test empty and populated tables, missing optional values, and the user contexts that are expected to access the data.

Use the table's Data action to inspect or prepare development records. Use Production Data only when production records need direct review or correction and the Project's subscription plan supports that access.

Table structure changes affect development records immediately. Production records are updated when the Project is published.

Publishing does not merge development records into a production table that already contains records. When the corresponding production table is empty, publishing copies that table's development records into it. Review development records and the state of each production table before publishing.

Custom integrations or external services can have their own environments and side effects; confirm their configuration separately.

For more information, see Table Data, Development and Production Data, and Previewing.

Example: Expanding an Event Registration Project

Suppose a Project already has an Events table and needs to start accepting registrations.

1. Create a Registrations table for attendee records rather than adding attendee information to the Events table itself.
2. Add the fields needed for the registration workflow.
3. Configure access so the intended users can submit registrations without receiving unnecessary permission to read or change other attendees' records.
4. Create a Table-Backed Form or custom frontend interface to collect the registration information.
5. Use permitted Database operations for straightforward record creation, or Cloud Flow when capacity limits and other trusted business rules must be enforced.
6. Test creation, editing, queries, and access rules against development data.
7. Publish when the configuration is ready, then verify the application through Launch Project.

The table defines the persistent records. The Form or custom interface collects input. Page Flow or custom JavaScript coordinates the browser-side experience. Cloud Flow can perform server-side checks when needed.

Good Practices

• Keep tables focused. Model recognizable application concepts rather than unrelated data in one structure.
• Choose stable names. Table identifiers are easier to maintain when their meaning does not change.
• Add fields intentionally. Start with the current workflow and evolve the structure as needed.
• Configure access early. Plan permissions before exposing records through interfaces or APIs.
• Review dependencies before structural changes. Check Forms, Widgets, queries, Page Flow, Cloud Flow, and AI Agents.
• Inspect clones. Confirm what the new table contains and configure it for its intended purpose.
• Test with development data. Use realistic records and verify both permitted and denied operations.
• Use direct record edits carefully. Table Data is useful for setup and inspection, but user-facing workflows still need to be tested.
• Plan structural edits. Added and removed fields update development records immediately and production records on publish.
• Review publishing impact. Saving or testing a change is not a substitute for evaluating the published workflow.

Common Mistakes

Avoid these patterns:

• Creating one large table for unrelated application data.
• Naming tables after temporary UI elements or Pages.
• Changing or replacing fields without checking their references.
• Changing User Input or automatic-value behavior without considering every create workflow.
• Assuming a cloned table includes data or automatically inherits every dependency.
• Treating a clone as a guaranteed rollback mechanism.
• Treating direct Table Data edits as proof that the normal user workflow works.
• Deleting a table before checking Backend, AI Agent, and published-app usage.
• Assuming a structural table change has no immediate effect on development records.
• Assuming publishing always copies development records into production.

Table management is most reliable when names and structures stay understandable, access is intentional, and changes are reviewed against the workflows that depend on them.

Related Topics

• Database
• Table Fields
• Table Access
• Queries
• Table Data
• Development and Production Data
• File Fields
• Using Database from Pages
• Using Database from Cloud Flow
• Forms
• Cloud Flow