Appearance
Table Data
Table Data lets you inspect, create, edit, and delete records in a Project Database table from the Project Editor.
Use it to prepare development test data, verify that Forms and workflows save the expected values, investigate unexpected results, and—where supported—inspect or administer production records.
Table Data is an authoring and data-management tool. It is different from a Data Table Widget, which presents records to users inside a Page, and from Queries, which define reusable data retrieval patterns.
Development and Production Views
A table's action menu provides two record views:
| Action | Purpose |
|---|---|
| Data | Inspect and manage records in the Project's development database. |
| Production Data | Inspect and manage live records in the production database, where the subscription plan supports this capability. |
Both views work with the selected table definition, but they contain separate sets of records.
Use Data for ordinary development and testing. Open Production Data only when you intentionally need to inspect or modify live information.
During Preview, built-in Database operations automatically use the development database. This includes built-in reads, creates, updates, and deletes. A Form or Data Table Widget tested through Preview therefore works with development records when using these operations; it does not change production records through the built-in Database operations.
For a detailed explanation of environment behavior, publishing, and record copying, see Development and Production Data.
Opening Table Data
To open a table's records:
- Open the Project in the Project Editor.
- Go to Backend → Database.
- Find the intended table and open its action menu.
- Choose Data for development records, or Production Data when live-record access is available and intended.
- Review the table name and the current data environment before making changes.
The Table Data view opens for the selected table. The Production Data view is identified as production so you can distinguish it from normal development records.
Use Close to return to the table listing.
Choosing the Correct View
| Task | Recommended View |
|---|---|
| Prepare example customer or registration records | Data |
| Test a new Form or Page Flow workflow | Data |
| Verify values created by a Page in Preview | Data |
| Create records for query testing | Data |
| Investigate a problem involving published records | Production Data, when available |
| Correct a live record as an administrative action | Production Data, when available and authorized |
Do not use Production Data as a substitute for creating development test records.
Understanding the Record List
The Table Data browser shows records from the selected table. Each row represents a record, while columns present fields included in the browser's listing.
Use the list to check whether:
- A record was created or updated successfully.
- A field contains the expected value.
- Optional values are empty when expected.
- Status, date, or numeric fields contain realistic values.
- File fields have the expected associated values.
- Test records represent different conditions that the application needs to handle.
For example, after submitting a registration Form in Preview, open the Registrations table's Data view to confirm that the new development record contains the attendee, event, and status values expected from that submission.
The browser shows stored data. It does not by itself prove that the corresponding Page, Form, Widget, or Cloud Flow workflow behaves correctly for every user.
Searching, Refreshing, and Downloading
Search
Use the Table Data Search box to narrow the visible records by text found in Text fields shown in the current table view. Numeric, Date/Time, Yes/No, and other non-Text fields are not searched by this control.
Search is useful when looking for a known name, email, record identifier, status, or other recognizable value in a table containing many records.
If an expected record is missing, clear the search and confirm that you are in the correct table and data environment before concluding that the record was not saved.
Table Data Search is not the same as a named query's Search Criteria. It is a record-browser convenience, not a way to configure or test a saved named query.
Refresh
Use Refresh to reload the table's records. Refresh also clears the current search text.
Refresh after testing operations that may change data, including:
- A Form submission.
- A Data Table Widget New or Edit action.
- A Page Flow or custom frontend data operation.
- A Cloud Flow workflow.
- Another Creator's changes to the same development table.
Refreshing helps distinguish stale browser content from a record that was not actually created or updated.
Paging Controls
The shared record-browser interface includes paging controls, but the Project Editor's Table Data view does not set a page size. It loads all records and disables the previous and next buttons.
Paging remains available to other interfaces that configure the shared table component with a positive page size. Do not describe the paging controls as active in the Project Editor's current Table Data view.
Download
Use the Download control when you need to export table data for inspection or debugging. The CSV contains the records currently displayed by the Table Data view. If Search is active, the download contains the filtered records rather than the unfiltered set.
Treat downloaded data as Project information that may contain names, contact details, record identifiers, file references, or other sensitive values. Limit distribution and storage of exports as appropriate.
The download control is separate from the published application's Data Table Widget export behavior. Test each in its own context rather than assuming they export identical sets of records.
Creating and Editing Records
The record editor uses the table's schema to present its fields with suitable inputs where supported.
Manual record editing is useful for test preparation, data inspection, and intentional administrative corrections. It should not replace testing the actual user-facing workflow.
Adding a Record
Use New to add a record directly to the current data environment.
- Open the intended table's Data view.
- Select New.
- Enter values in the generated record editor.
- Save the record.
- Confirm that the record appears with the expected values, using Refresh if needed.
For example, you could create several registration records with statuses such as Pending, Confirmed, and Cancelled before building an administrative results Page.
Manual test records can also represent situations that are difficult to create through ordinary Forms, such as unusually long descriptions, older dates, missing optional values, or records associated with different categories.
Editing a Record
To change a stored record:
- Find the record in the correct Table Data view.
- Select its row and choose Edit.
- Review the existing field values.
- Change the intended values and save.
- Confirm that the record shows the updated values.
For example, changing a test registration's status from Pending to Confirmed can help verify that a Data Table Widget, a status Badge, or a named query displays the correct result.
Direct table edits may not follow the same validation and business-rule path as a Form, Page Flow, or Cloud Flow. Use direct edits to prepare or inspect records, then run the actual workflow to confirm its behavior.
Deleting a Record
For an existing record, the record editor provides a delete action.
Deletion affects the environment currently being viewed:
| Current View | Effect |
|---|---|
| Data | Deletes the development record. |
| Production Data | Deletes a live production record, where this view is available. |
Before deleting a record, consider whether it is referenced by another table, a file field, a Page, a Widget, a Cloud Flow, an AI Agent, or another part of the application.
Deleting a parent or related record can leave other records referring to an item that no longer exists. The resulting effects depend on the application's data model and workflows; do not assume automatic cleanup of related records.
For production records, confirm the table, record, and business impact before proceeding.
A Practical Development-Data Workflow
Consider an event registration Project with Events and Registrations tables.
1. Prepare Representative Records
Open Data for the Events table and add test events. Then open Data for the Registrations table and add records associated with those events.
Prepare cases such as:
| Test Record | Purpose |
|---|---|
Registration with Confirmed status | Test standard display and filtering. |
Registration with Pending status | Test review workflows. |
| Registration with long attendee notes | Test table width and Form layout. |
| Registration with an empty optional field | Test missing-value handling. |
| Registration for another event | Test query conditions. |
| Registration linked to another user or group | Test authorization through the runtime interface. |
The names and statuses are example application values, not fields or status options created automatically by ioLoop.
2. Test the User Workflow
Preview the Page that opens the registration Form. Submit a new registration, then return to the Registrations table's Data view and use Refresh to inspect the result.
Test New and Edit operations separately. A successful manual edit does not establish that the Form correctly identifies or updates the intended record.
3. Test Queries and Displays
Run the configured named query through the Page, Widget, Page Flow, or other component that uses it. Confirm that matching registrations appear, unrelated registrations are excluded, and the intended fields are displayed.
Use Table Data to investigate stored values if the output is unexpected. Do not treat Table Data Search as evidence that the named query is configured correctly.
4. Test Error and Empty States
Test a query with no matching records, an invalid submission, and a user who should not be permitted to perform a protected operation.
Verify what the user sees, not only what appears in the Table Data browser.
File Fields in Table Data
When a table includes file-oriented fields, the record editor provides the supported controls for those fields.
Use Table Data to inspect file values or set up file-related test cases. Then verify the corresponding user-facing behavior, such as upload, display, replacement, download, or deletion, through the relevant Form or workflow.
Be particularly careful when editing production records with file associations. A changed record may affect later file access or processing by other application components.
Database file fields are not the same as Project Media. File fields associate files with records; Media stores public frontend assets. File access depends on the applicable Database permissions and file-handling workflow, not simply on whether a link is visible.
For more information, see File Fields.
Table Data and Named Queries
Use Table Data to create and inspect test records, then verify named queries separately.
A named query can involve:
- Search Criteria that select matching records.
- Field Selection that controls which values are returned.
- Data Joins that include related information.
- Sorting Order that determines how results are arranged.
- Runtime inputs used by parameterized queries.
The Table Data search box does not test those query settings. For example, searching for a customer name in Table Data does not verify that a query correctly joins orders with customers.
For detailed query configuration and testing, see Queries.
Table Data and Access Rules
Creators inspect records through the Project Editor, whereas Project Users interact with records through published Pages and supported runtime APIs.
A record being visible in Table Data does not mean that every Project User is authorized to read or modify it.
When testing access, use the appropriate Preview user context and verify the real data operation from the Page, Form, Widget, Page Flow, or custom frontend implementation.
Check both permitted and denied cases. For sensitive workflows, verify that Cloud Flow or other trusted Backend logic enforces the required record-specific rules.
For details, see Table Access.
Table Structure and Existing Records
Table Data reflects the current table definition. Schema changes have specific effects on existing records:
| Change | Development Records | Production Records |
|---|---|---|
| Add a field | Existing records receive the field immediately, with a default value based on the field type. | Existing records receive the structural change when the Project is published. |
| Remove a field | The field is removed from existing development records immediately. | The field is removed from production records when the Project is published. |
| Change a field type | Existing values are converted to the new type immediately; conversion may be lossy or may produce defaults. | Existing values are converted when the Project is published. |
Review the effect of schema changes on existing records, Forms, named queries, Widgets, Page Flow, Cloud Flow, and custom JavaScript before publishing.
Development Records and Publishing
Publishing normally releases Project configuration and table-structure changes. Record behavior depends on whether the corresponding production table already contains records.
When the corresponding production table is empty, publishing copies that table's development records into it. If the production table already contains records, publishing does not merge in development records or overwrite its existing records. Review development test data before publishing an empty production table.
These lifecycle rules are covered in detail in Development and Production Data.
Troubleshooting Table Data
| Issue | What to Check |
|---|---|
| Expected record is missing | Correct table, development versus production view, current Search text, and whether the operation succeeded. The Project Editor view loads all records rather than paging them. |
| A recently saved change is not visible | Use Refresh and confirm that the workflow wrote to the environment being viewed. |
| New record cannot be saved | Field types, User Input settings, entered values, uniqueness constraints, and any error shown by the record editor. |
| Unexpected field values | Table schema, defaults, the submitting workflow, and whether a direct edit bypassed its normal processing. |
| Records differ from Preview | Check that you are inspecting development data; built-in Database operations during Preview use development records. |
| Records differ from the published application | Confirm the Production Data view and remember that development and production records are separate. |
| Query results differ from the table browser | Verify the named query's Search Criteria, Field Selection, Data Joins, Sorting Order, and inputs. |
| A file value behaves unexpectedly | Review the file field, associated record, and actual upload or file-access workflow. |
| A user cannot access a visible record | Check Table Access and any trusted Backend authorization; editor visibility does not establish runtime permission. |
| A field disappeared after editing the table | Review schema changes and whether the field was removed from existing development records. |
If the data is correct in Table Data but incorrect on a Page, test the consuming Form, Widget, query, or Page Flow separately. This helps identify whether the problem is in stored values, data retrieval, or presentation.
Good Practices
- Use development records for testing. Prepare sample data in Data rather than experimenting with live records.
- Check the environment before editing. Production Data changes affect the published application's records.
- Use representative records. Test different statuses, missing values, long text, and related-record cases.
- Refresh after running a workflow. Confirm changes against the latest stored data.
- Test the actual user path. Manual record edits do not replace Form, Widget, Page Flow, or Cloud Flow testing.
- Test query behavior separately. Table Data Search is not a substitute for testing named queries.
- Test access as intended users. Creator access to the editor is not proof of Project User permissions.
- Review exports and file associations. Handle downloaded data and record-owned files appropriately.
- Plan schema changes. Understand when development and production records are reshaped.
Common Mistakes
Avoid these patterns:
- Editing Production Data while intending to change development test records.
- Assuming built-in Database operations in Preview write to production.
- Treating direct record edits as proof that a Form or Cloud Flow works correctly.
- Leaving Search active when looking for a missing record.
- Confusing Table Data Search with a saved query's Search Criteria.
- Assuming a deleted record has no related dependencies.
- Treating editor access to a record as proof that a Project User can access it.
- Assuming publishing always copies development records into production.
- Forgetting that adding or removing table fields changes existing records.
- Testing only ideal records and never testing missing or invalid values.
Table Data is most effective when used to prepare, inspect, and verify records alongside the actual application workflows. Use it for development testing, and treat direct production record changes as deliberate administrative operations.