One kind of record per table
Use a table for each main entity, such as Customers, Jobs or Assets. Each row is a record; each field holds an attribute. Keep a stable key for relationships. A display label is not necessarily the stored identifier used by formulas or integrations.
Choose field types
- Text for names, descriptions and identifiers that are not quantities.
- Number and Currency for quantities and money; keep the app currency consistent.
- Date and DateTime for dates and timestamps.
- Choice for controlled values, with a custom Other value where enabled.
- Boolean for yes/no, Rating for a score and User for a person.
- Lookup for a related record, Calculated for a formula, File or Image for an attachment.
Configure and test
- Open the table/schema editor and choose the table.
- Add or edit the field type and display label.
- Set required input and available length, minimum, maximum or pattern rules.
- Set visibility deliberately; do not hide a required field people must supply.
- Save, then test valid and invalid values in the record form.
Defaults
Defaults initialise new-record forms. They do not rewrite existing records or replace values already supplied by a person or parent form. Supported tokens include {{TODAY}} and {{User.Email}}. Choose a default compatible with the field type.
Example and precautions
Tasks might contain required Title text, a DueDate, a Priority choice and EstimatedCost currency. A blank Title should prevent a valid save; a completed form should create one record.
Structural changes can affect data, imports, formulas and workflows. Export important data before destructive changes. Changing a display label is not a data migration.