Appearance
Table Fields
Fields define the values stored in each record of a Project Database table. A field has a generated identifier, a display title, a type, and settings that control input, searching, uniqueness, indexing, and automatic values.
For creating, cloning, and deleting tables, see Managing Tables.
Adding a Field
- Open Backend → Database in the Project Editor.
- Edit the table that should contain the field.
- Add a field.
- Enter a Field Title.
- Select its Type and, where available, its Sub-Type.
- Configure the settings needed by the application.
- Save the field, then save the table.
- Test the changed table and its dependent workflows with development data.
Saving a table-structure change updates the development database. The equivalent change is applied to the production database only when the Project is published.
Field Title and Field ID
The editor distinguishes the field's title from its identifier.
| Setting | Purpose |
|---|---|
| Field Title | The editable, Creator-facing title for the field. |
| Field ID | The generated, read-only identifier used by queries, flows, APIs, and other Project configuration. |
The Field ID is generated when a new field is created and cannot be edited in the field editor. Changing the Field Title later does not rename the Field ID.
Use the Field ID expected by the relevant Page Flow block, Cloud Flow block, or API. Do not substitute a Form label or Field Title where an identifier is required.
Field Types and Sub-Types
The following types are available when creating or editing fields in the Project Editor.
| Type | What It Stores | Available Sub-Types |
|---|---|---|
| Text | Text values. | Allow any text, Multi-line, Multi-line HTML, Email, Phone, Password, List of Values, Files |
| Numeric | Whole numbers up to 9 digits. | None |
| Numeric (decimals) | Numbers with decimals. | None |
| Date/Time | Dates, times, or both. | Date and Time, Date only, Time only, Custom |
| Yes/No | Boolean values such as Yes/No, True/False, or On/Off. | None |
| Large Numeric | Whole numbers up to 18 digits. | None |
An advanced ObjectID reference type exists internally but is not offered in the normal Creator field-type selector. For normal table design, use the types and sub-types shown by the editor.
Text Sub-Types
| Sub-Type | Use |
|---|---|
| Allow any text | General names, titles, codes, and other single-line text. |
| Multi-line | Longer plain-text content. |
| Multi-line HTML | Multi-line HTML content. Treat stored HTML as active content and apply appropriate trust and sanitization rules. |
| Email-address input and presentation. | |
| Phone | Phone-number input and presentation. |
| Password | Password-style input. Do not assume that choosing this sub-type alone implements an application authentication or credential-storage design. |
| List of Values | A value selected from a defined list. Enter the allowed choices as a comma-separated list in Values. |
| Files | One or more files associated with a record. See File Fields. |
Files is a Text sub-types, not separate top-level field types.
Numeric Types
Use Numeric for whole numbers up to 9 digits and Large Numeric for whole numbers up to 18 digits. Use Numeric (decimals) when fractional values are needed.
Phone numbers, postal codes, account codes, and other identifiers are normally Text values even when they contain only digits. Storing them as numbers can remove leading zeros and implies arithmetic semantics that do not apply.
Date/Time Sub-Types
Choose the sub-type that matches the intended input and display:
- Date and Time for a combined date and time.
- Date only when the time is not part of the value shown to the user.
- Time only when only a time is needed.
- Custom for a custom date/time presentation supported by the consuming interface.
Plan timezone behavior in the Pages, flows, and integrations that create and consume date values.
Field Settings
The editor displays settings supported by the selected type.
| Setting | Behavior |
|---|---|
| Unique | Prevents duplicate values for the field. |
| Description | Records a short description of the field. |
| Values | Supplies values required by certain types, including the comma-separated choices for List of Values. |
| Index | Creates an index for the field. Use it for fields that need indexed access; do not enable it indiscriminately. |
| Disallow Search | Excludes the field from general record searching. |
Index and Disallow Search are under Advanced.
Structural Changes and Existing Records
Field changes reshape existing records; they do not apply only to records created later.
| Change | Development Database | Production Database |
|---|---|---|
| Add field | When the table change is saved, the field is added to every existing development record with a type-based default value. | The same change is applied to existing production records when the Project is published. |
| Remove field | When the table change is saved, the field is removed from every existing development record. | The field is removed from production records when the Project is published. |
| Change field type | When the table change is saved, existing development values are converted to the new type. | Existing production values are converted when the Project is published. |
| Change other settings | The development schema uses the new settings after the table is saved. | The published schema uses them after the Project is published. |
Adding a field uses these defaults:
| Type | Value Added to Existing Records |
|---|---|
| Text | Empty text ("") |
| Numeric | 0 |
| Numeric (decimals) | 0.0 |
| Date/Time | The current local date and time when the migration runs |
| Yes/No | false |
| Large Numeric | 0 |
Sub-types do not change these storage-type defaults. For example, a new Text field using the Files sub-type initially receives an empty text value in existing records.
Changing a Field Type
ioLoop converts existing values when a field's top-level type changes. Conversion can be lossy or can produce defaults when an old value does not have a useful representation in the new type.
Before saving a type change:
- Inspect representative development values.
- Identify Forms, queries, Widgets, Page Flow, Cloud Flow, AI Agents, and custom code that use the field.
- Save the change and inspect the converted development records.
- Test every dependent workflow in Preview.
- Review how the same conversion will affect production records when published.
Do not use a type change as a substitute for a planned data transformation when the exact converted value matters.
Removing a Field
Removing a field deletes it from existing development records as soon as the table change is saved, and from production records when the change is published. Before removal, check all consumers of the Field ID and determine whether its data must be retained elsewhere.
Example: Registration Fields
| Field Title | Example Type and Sub-Type | Purpose |
|---|---|---|
| Attendee Name | Text — Allow any text | Stores the attendee's name. |
| Email Address | Text — Email | Stores contact information. |
| Ticket Type | Text — List of Values | Restricts entry to the configured ticket choices. |
| Checked In | Yes/No | Tracks whether check-in has occurred. |
| Registered At | Date/Time — Date and Time | Stores registration timing. |
| Attachment | Text — Files | Associates one or more files with the record. |
These are example titles. Use the generated Field IDs shown in your table when configuring queries, flows, or API calls.
Development and Production Workflow
Use this sequence for field changes:
- Change and save the table in the Project Editor.
- Inspect existing records under Data. They already reflect the updated development schema.
- Test create, edit, search, query, file, and access behavior in Preview.
- Review the defaults, removals, or conversions that will be applied to live records.
- Publish the Project when the change is ready.
- Verify the affected workflows and production records after publishing.
Publishing applies the schema change to production; it 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. See Development and Production Data.
Good Practices
- Use a clear Field Title and treat the generated Field ID as a stable dependency.
- Choose the top-level type for storage behavior and the sub-type for the intended input or presentation behavior.
- Use List of Values when the editor should constrain input to a known set of choices.
- Test field additions, removals, and type conversions against existing development records before publishing.
- Review permissions and trusted validation for sensitive or business-critical values.
- Use Database file fields for files belonging to records and Media for public interface assets.
Common Mistakes
- Treating Field Title and Field ID as the same value.
- Omitting the selected sub-type when documenting or reviewing a field.
- Assuming a newly added field remains absent from existing records.
- Assuming a type change leaves existing values untouched.
- Forgetting that production records change only when the Project is published.
- Expecting publishing to merge development records into an existing production database.
- Treating a hidden Form control or a query projection as a security boundary.