In a team task tracker, “Prepare the launch checklist” is one record. Its title, due date, and completion state are fields. The Tasks table describes which fields every task can have.
The simple idea: define the information once, then show or edit it in different views.
Use a table for a kind of thing: Tasks, Projects, or Equipment. “Table” describes the data structure here; it does not require a spreadsheet-style screen.
Each record is one instance of that thing. Each field answers one question about it:
| Field | Example | Meaning |
|---|---|---|
| Title | Prepare the launch checklist | Text describing the task |
| Complete | No | A yes/no value |
| Due date | October 23, 2026 | A calendar date |
| Status | In progress | A configured choice |
Choose a field type that matches its meaning. A calendar date is different from a date and time; a number is different from an exact money amount. Available field types and controls depend on the current builder.
A task can link to a project record. This is useful when several tasks belong to one project: the task stores a reference rather than repeating the project's information.
Supported record links are many-to-one. Do not assume arbitrary many-to-many relationships are available. A person field references an app account, which is distinct from your Appify builder account.
A list and a detail screen can display the same task. Changing a screen's heading or field order does not create another copy of that task.
Required fields and access rules affect the underlying records. A screen filter only changes what you are browsing; it cannot replace an access rule.
Starter examples and builder sample records help you explore the app. They are synthetic preview material, not records that automatically become production data. Use fictional names and tasks while learning.