Good table design is the foundation of every successful TrackVia application. Decisions made when structuring tables ripple into every view, form, formula, and Flow you build later. This guide collects the design principles taught in TrackVia University's Tables course.
1. One Table, One Kind of Thing
Each table should represent a single type of real-world entity: Customers, Orders, Assets, Inspections. If you find yourself adding fields like "Customer Name" and "Order Date" and "Inspection Result" to the same table, that table is doing several jobs — split it and connect the pieces with relationships.
Signs a table needs splitting:
- Repeated field groups (Item 1, Item 2, Item 3...) — those should be child records
- Many fields that are blank for most records
- The table participates in an unusually large number of relationships (a [join limit] risk)
2. Choose Field Types Deliberately
Pick the field type that matches how the data will be used, not just how it looks. Consult the Field Types reference before building. A few common decisions:
- Drop Down vs. Single Line text: If values should come from a controlled list (statuses, categories), use a Drop Down — free text invites typos that break filters and reports. But note that Drop Down values do not appear in searches, and each Drop Down field consumes a join.
- Drop Down vs. a related table: If the "list" has its own data (a Region with a manager and a target), make it a table and use a relationship instead of a Drop Down.
- Number vs. Single Line for identifiers: Use text for identifiers like ZIP codes or part numbers with leading zeros — numeric fields strip leading zeros.
- Date vs. Date and Time: Only add the time component if you need it; it introduces time-zone display behavior.
- Attachments vs. multiple Image/Document fields: One Attachments field holds up to 25 files and consumes only one join.
3. Plan for the Join Limit
Tables have a hard limit of 61 joins, and 2 are used by default (the built-in Created By and Last Updated By fields), leaving 59 for your design. Relationships, Drop Down, Image, Document, Attachments, Application User, and Application Group fields each consume one join, and Calculated/Triggered fields that reference those field types consume one or more — two if the referenced field lives on a parent or child table, and potentially many more when calculations reference other calculations. Estimate join usage per table before you build, and be especially wary of long calculation chains. See Understanding the Join Limit.
4. Set Well-Formed Record IDs Early
The Record ID is how users identify records in views, searches, and Link to Parent drop-downs. Configure it as soon as the table's key fields exist, and include a guaranteed-unique component (like an Auto Counter) when names can repeat. See How to Configure a Record ID.
5. Use Consistent, Human Naming
- Name tables as plural nouns ("Customers," "Work Orders") and fields as concise labels users will recognize on forms.
- Keep relationship names meaningful — they become column headers in child views and labels on forms.
- Avoid commas in Checkbox field options (they break imports and integrations).
6. Use Relationships Instead of Duplicating Data
If the same information lives in two tables, it will eventually disagree with itself. Store each fact once, in the table it belongs to, and surface it elsewhere through relationships and calculated lookups. Across applications, use Cross-App Connect to share one table rather than maintaining copies.
7. Prototype in a Sandbox
For significant new builds or restructures on a production account, work in a sandbox first. Deleting fields and tables destroys data permanently; a sandbox makes experimentation safe.
8. Design for Growth
- Will this table hold 500 records or 500,000? For large tables, plan Table Level Indexing on the fields users search.
- Will other apps need this data later? Structure it as a shareable, single-purpose table from the start.
- Leave room for statuses and lifecycle: an "Archived" or "Status" field from day one beats retrofitting one across thousands of records.
Comments
0 comments
Please sign in to leave a comment.