Tables
Tables are where your structured data lives. App Builder uses them as a direct data source — perfect for dashboards, lists, search pages, and trackers where the data has a defined, stable structure.
Unlike workflows, tables have an immediately visible schema. As soon as you add a table as a resource, App Builder knows its columns and you can prompt against it straight away.
What tables are good for
| Use case | Example |
|---|---|
| Master data | Suppliers, items, locations, customers |
| Transactional records | Orders, invoices, goods receipts |
| Configuration and lookup data | Categories, statuses, regions |
| Data enrichment | Supplementary fields added to records from other sources |
| User preferences | Watchlists, favourites, personal settings |
Adding a table as a resource
- Open the Resources panel in App Builder.
- Click Add resource and select your table.
- Assign a descriptive alias — for example,
invoice_tableorsupplier_list. - Prompt immediately — no warmup runs needed.
Designing tables that work well in apps
The table schema directly affects what App Builder can do with it. Follow these practices:
| Practice | Why |
|---|---|
| Use descriptive column names | supplier_name tells App Builder more than c1 — better field selection in prompts |
| Use the correct data types | Dates as dates, numbers as numbers — enables sorting and range filtering |
| Include an identifier column | Needed for linking list views to detail views |
| One row per entity | Avoids ambiguity in grouping and aggregation |
| Avoid implicit context in column names | status alone is ambiguous; order_status is clear |
Updating an existing table
When you add or rename columns in a table, App Builder detects the schema change immediately. You still need to re-prompt the app to tell the AI about the new or changed fields — the app does not update its UI automatically.
When you add a column to a table, open the app in a new build session and tell the AI exactly what changed: "The invoice_table now has a priority column. Show priority next to status in the list."
Common app patterns using tables
- Master data directory — browse and search a full list of suppliers, items, or locations
- Transactional dashboard — chart and filter orders or invoices by status, date, or region
- Activity tracker — highlight records that need action, grouped by priority or assignee
- Data enrichment layer — display supplementary context alongside M3 data fetched by a workflow
- User watchlist — let users save and revisit records they are monitoring