Appearance
Database
Database is where you create, organize, and manage the structured data used by an ioLoop Project. It provides tables, fields, access rules, named queries, and records that can be used by both frontend and backend functionality.
Use Database for information that belongs to your application, such as customers, registrations, orders, events, tasks, support requests, catalog items, and files associated with records.
Database works with Pages, Forms, Widgets, Data Design, Page Flow, Cloud Flow, AI Agents, and custom code using the supported ioLoop APIs.
How Database Works
A Project Database is organized into tables. Each table represents a type of application record and defines the fields that those records contain.
| Concept | Purpose |
|---|---|
| Table | Stores records for an application concept, such as Customers or Registrations. |
| Field | Defines a value stored in a record, such as a name, date, status, amount, or file. |
| Access Rules | Define which Project Users or User Groups can perform permitted data operations. |
| Named Query | Provides a reusable way to retrieve records using configured query behavior. |
| Table Data | Lets Creators inspect and manage records in the applicable data environment. |
| Development and Production Data | Separate data used for development testing from data used by the published application, where supported by the Project plan. |
For example, an event registration application may use an Events table to describe events and a Registrations table to store attendee registrations. Pages display event information, Forms collect registrations, and server-side workflows can enforce registration rules when required.
What You Can Do in Database
Use the Database section to:
- Create, edit, clone, and delete Project tables.
- Define fields and choose supported field types and sub-types.
- Configure View, Add, Modify, and Delete table access rules.
- Create and maintain named queries.
- Inspect and work with development data and, where available, production data.
- Use file fields for uploads or generated files associated with records.
A table may be referenced by many other Project components. Before changing or deleting an existing table, field, or query, review the Forms, Widgets, Page Flow, Cloud Flow, AI Agents, and custom code that depend on it.
Using Database Throughout a Project
Different Project components can use the same Database without requiring every data operation to be implemented in Cloud Flow.
| Project Area | How It Uses Database |
|---|---|
| Pages and Forms | Collect, display, create, or edit permitted records. |
| Data Table Widget | Displays records in a configured table interface with supported record actions. |
| Data Design | Presents retrieved records in custom repeated layouts. |
| Page Flow and custom frontend code | Use supported ioLoop Client APIs to read or change permitted data and coordinate the interface. |
| Cloud Flow and custom backend code | Use server-side Database capabilities to process data and enforce trusted business rules. |
| AI Agents | Use appropriately configured Table Knowledge Sources and related capabilities. |
Built-in frontend components and custom frontend implementations use the same underlying ioLoop Client API capabilities. Forms, Widgets, and Page Flow provide ready-made or visual approaches; custom HTML and JavaScript can implement equivalent data-driven experiences directly through the Client APIs.
For permitted data access, a Page or custom frontend does not automatically need Cloud Flow. Use Cloud Flow when operations require protected credentials, server-side authorization, centrally enforced business rules, or trusted processing. Whether implemented visually or in code, data operations must respect the applicable access and security requirements.
For implementation guidance, see Using Database from Pages and Using Database from Cloud Flow.
Development and Production Data
ioLoop distinguishes data used during development from data used by the published application, where supported by the subscription plan.
- Development Data is used to build and test workflows in the Project Editor.
- Production Data is used by the published application and may contain live user records.
During Preview, all built-in Database operations automatically use the development database. This applies to built-in reads, creates, updates, and deletes, including those performed through supported Forms and Widgets. No additional environment selection is required for these operations.
Saving table-structure changes updates the development database and its existing records. The production database is updated only when the Project is published. Publishing does not normally copy development records into production. Test with representative development data, then verify the published application using the appropriate production context.
Cloud Flow, custom code, and external Integrations can have additional environment or connection considerations. Do not assume that a call to an external service is automatically switched to a test environment during Preview.
For details, see Development and Production Data and Previewing.
Access and Security
A table may be used by public visitors, signed-in Project Users, administrators, Page Flow, Cloud Flow, and AI Agents. Those uses do not necessarily require the same permissions.
Configure access intentionally for the operations the application needs. For example, a public visitor might be permitted to create a contact request without being allowed to read all submitted requests.
Hiding an element, filtering a displayed list, or disabling a button does not secure the underlying data. Table access rules and trusted Backend authorization remain important regardless of whether an application uses built-in components or custom Client API code.
For the available permission model and implementation guidance, see Table Access.
Typical Database Workflow
A common approach to adding data-backed functionality is:
- Define the records. Identify the application concepts and create the required tables.
- Configure fields. Choose field types and sub-types, decide whether values come from user input or the system, and configure file fields where appropriate.
- Plan access. Set permissions for the users and operations the application should support.
- Add retrieval patterns. Create named queries when the same filtered or sorted records are needed repeatedly.
- Connect the application. Use Forms, Widgets, Page Flow, Cloud Flow, AI Agents, or custom code as appropriate.
- Test before publishing. Use development data to verify reads, writes, errors, permissions, and the full user workflow.
These steps are an authoring pattern, not a required order for every Project. Detailed editor operations are covered in the guides below.
In This Section
| Guide | What You Will Learn |
|---|---|
| Managing Tables | Create, edit, clone, name, and delete tables while managing dependencies. |
| Table Fields | Configure Field Titles and generated Field IDs, choose types and sub-types, and understand User Input and structural changes. |
| Table Access | Configure data-operation permissions and understand their security implications. |
| Queries | Define, reuse, maintain, and test named queries. |
| Table Data | View and manage records while developing and testing the Project. |
| Development and Production Data | Understand separate data environments and publishing considerations. |
| File Fields | Associate uploaded or generated files with Database records. |
| Using Database from Pages | Use data from Forms, Data Table Widgets, Data Design, Page Flow, and frontend code. |
| Using Database from Cloud Flow | Implement trusted server-side Database workflows and authorization checks. |
Technical Reference
This section explains Database concepts and Project Editor workflows. For exact block inputs, outputs, and API signatures, see the auto-generated Programming Guide:
Good Practices
- Model each table around a clear application concept.
- Treat generated Field IDs and query names as stable dependencies after other Project components begin using them.
- Configure access rules while designing the workflow, not only before publishing.
- Use named queries for retrieval patterns shared across application components.
- Test with realistic development records, including empty results and denied operations.
- Use Cloud Flow when an operation needs trusted enforcement, not simply because it uses Database.
Common Mistakes
Avoid these patterns:
- Changing or deleting a shared table or query without reviewing its dependencies.
- Treating a named query, hidden control, or client-side condition as authorization.
- Assuming every Database operation requires Cloud Flow.
- Assuming Preview changes production records through built-in Database operations.
- Assuming publishing copies development data records into production.
- Treating public frontend Media and record-associated file fields as interchangeable.