7.1 Understanding Sub-Taibles
You've mastered triggers, dependencies, and conditions. Your automations can handle single entities—one lead, one order, one contact. But what about relationships?
- One order with multiple line items
- One contact with many interactions
- One project with dozens of tasks
- One invoice with several line items
- One email thread with many messages
This is where sub-taibles come in—they handle one-to-many relationships elegantly.
The Problem: When One Row Isn't Enough
Scenario: E-commerce Orders
Imagine you're automating order processing. Each order has:
- Order details (customer, date, status)
- Multiple line items (products ordered)
- Each line item has: product name, quantity, price
How do you model this in a single row?
Attempt 1: All Data in One Cell (Doesn't Work)
Structure:
| Order ID | Customer | Line Items |
|---|---|---|
| 1001 | John | [Product A × 2, Product B × 1, Product C × 3] |
❌ Problems with this approach:
- • Can't calculate totals for each item
- • Can't process items separately
- • Can't add columns for item-specific data
- • Becomes messy with many items
The problem:
- Can't easily calculate line totals
- Can't process each item separately
- Can't have columns for item-specific operations
- Hard to query "all orders containing Product A"
- Messy when order has 20+ items
Attempt 2: Multiple Rows (Loses Relationship)
Structure:
| Order ID | Customer | Product | Quantity | Price |
|---|---|---|---|---|
| 1001 | John | Product A | 2 | $10 |
| 1001 | John | Product B | 1 | $20 |
| 1001 | John | Product C | 3 | $15 |
❌ Problems with this approach:
- • Order details duplicated (highlighted in yellow)
- • Hard to know which rows belong together
- • Can't have order-level columns
- • No clear relationship structure
The problem:
- Order details duplicated across rows
- Hard to know which rows belong together
- Can't have order-level columns (total, shipping, status)
- Hard to show "order with its items"
The Solution: Sub-Taibles (Perfect!)
Structure:
Orders Taible (Parent):
| Order ID | Customer | Status | Order Items |
|---|---|---|---|
| 1001 | John | Processing | 3 Entries |
Order Items Taible (Child):
| Product | Quantity | Price | Line Total |
|---|---|---|---|
| Product A | 2 | $10 | $20 |
| Product B | 1 | $20 | $20 |
| Product C | 3 | $15 | $45 |
✅ Why this works:
- • Order details in parent row (no duplication)
- • Each item in separate child row (easy processing)
- • Child rows linked to parent (clear relationship)
- • Can have columns in both tables (flexible)
- • Can combine children data to parent (sum totals)
Why this works:
- Order details in parent row
- Each item in separate child row
- Child rows linked to parent
- Can have columns in both tables
- Can combine data from children to parent (sum line totals = order total)
- Clear relationship
The Concept: Tables Within Tables
What is a Sub-Taible?
Simple definition: A sub-taible is a separate table whose rows belong to a parent row.
Think of it like:
- A folder (parent) containing files (children)
- A customer (parent) with orders (children)
- A project (parent) with tasks (children)
- A conversation (parent) with messages (children)
Key characteristics:
- Parent row = one entry in main table
- Child rows = multiple entries in sub-taible
- Link = each child "knows" its parent
- Nested view = children appear "inside" parent cell
Visual Mental Model
The Nested Table:
| Customer | Orders | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| John | john@acme.com | 5 Entries ↳ Orders Sub-Taible:
| ||||||||||||
| Sarah | sarah@co.com | 2 Entries |
The relationship: Parent row "contains" child rows
The Architecture
Two separate tables, connected:
1. Parent Taible (e.g., "Orders")
- Regular taible
- Has a special sub-taible column
- Sub-taible column shows: "X items" or item count
- Hover over cell to see an arrow button
- Click arrow button to navigate to child rows
2. Child Taible (e.g., "Order Line Items")
- Separate taible (has its own URL, own columns)
- Each row is linked to a specific parent row
- Can have triggers, calculated columns, everything parent can
- Header shows breadcrumb with parent context
The connection:
When to Use Sub-Taibles
Use Case 1: One-to-Many Collections
Pattern: Parent has multiple items of same type
Examples:
Order → Line Items
- Parent: Order (customer, date, shipping address)
- Children: Line items (product, quantity, price)
Invoice → Invoice Lines
- Parent: Invoice (customer, invoice date, due date)
- Children: Invoice lines (description, amount)
Project → Tasks
- Parent: Project (name, deadline, owner)
- Children: Tasks (task name, assignee, status)
Contact → Interactions
- Parent: Contact (name, email, company)
- Children: Interactions (date, type, notes)
When to use: Parent entity has multiple items that need individual processing
Use Case 2: Historical Records
Pattern: Track changes or events over time
Examples:
Customer → Purchase History
- Parent: Customer profile
- Children: Each purchase with details
User → Activity Log
- Parent: User account
- Children: Each login, action, change
Equipment → Maintenance Records
- Parent: Equipment (ID, model, location)
- Children: Maintenance events (date, work done, cost)
When to use: Need to track timeline of events for an entity
Use Case 3: Hierarchical Data
Pattern: Master record with detail records
Examples:
Email Thread → Messages
- Parent: Email thread (subject, participants)
- Children: Individual messages in thread
Support Ticket → Follow-ups
- Parent: Ticket (issue, customer, status)
- Children: Updates, responses, resolution attempts
Campaign → Campaign Runs
- Parent: Marketing campaign (name, budget, dates)
- Children: Individual campaign executions
When to use: Master record needs to track multiple related events
Use Case 4: Composition Relationships
Pattern: Whole is made up of parts
Examples:
Recipe → Ingredients
- Parent: Recipe (name, servings, instructions)
- Children: Ingredients (item, quantity, unit)
BOM (Bill of Materials) → Components
- Parent: Product assembly
- Children: Component parts needed
Curriculum → Lessons
- Parent: Course (name, instructor, duration)
- Children: Individual lessons
When to use: Parent object is composed of multiple sub-parts
What Sub-Taibles Enable
1. Separate Processing for Parent and Children
Parent-level operations:
- Calculate order total (sum children)
- Determine project status (based on task completion)
- Send customer summary (combine purchase history)
Child-level operations:
- Check inventory for each line item
- Assign each task to team member
- Track status of each invoice line
Example flow:
2. Independent Child Automation
Children have their own columns:
- Each child row can trigger automation
- Children can have dependencies between their columns
- Children can have conditions
- Children process independently
Example: Task Management
- • project_name
- • deadline
- • tasks (sub-taible)
- • completion_percentage (gathered from children)
- • task_name
- • assigned_to
- • status (Manual: "To Do", "In Progress", "Done")
- • status_changed_date (Calculated: timestamp when status changes)
- • send_notification (Calculated: notify assignee when task assigned)
- • overdue_alert (Scheduled: check if past due date)
Each task processes independently with full automation!
Each task processes independently with full automation!
3. Parent-Child Data Flow
Children can access parent data:
When you set up columns in the child taible, you can reference data from the parent row. The system automatically handles this connection.
Example: A shipping label column in line items can automatically pull the customer name and shipping address from the parent order.
Parent can combine child data:
Using the "Pull Data" column type, parent rows can gather information from all their children:
- Sum: Add up all line totals to get order total
- Count: Count how many items/tasks/records
- Average: Calculate average values
- Find highest/lowest: Get max or min values
- • Type: Pull Data
- • Source Taible: order_items (the sub-taible)
- • Source Column: line_total
- Pull Data retrieves all line_total values: [$20, $20, $45]
- Use a Transform or Custom Code column to sum them
- Result: $85 total
4. Natural Data Organization
Mimics real-world structure:
- Orders naturally have line items
- Projects naturally have tasks
- Customers naturally have interactions
UI reflects structure:
- Hover over sub-taible cell to see arrow button
- Click arrow button to view items
- Breadcrumb shows parent context
- Use back button to return to parent
Queries become intuitive:
- "Show me order #1001 and all its items"
- "Show me all tasks for Project Alpha"
- "Show me Sarah's purchase history"
How Sub-Taibles Work: The User Flow
Creating the Relationship
Step 1: Parent row exists
| Order ID | Customer | Date |
|---|---|---|
| #1001 | John | Oct 24 |
Step 2: Add sub-taible column to parent
When adding a column to your parent taible, you can choose the "Add Row" type. This special column type creates child rows in another taible.
When adding a column, select the Add Row type.
- • Column Name: order_items
- • Type: Add Row (creates children in another taible)
- • Target Taible: Order Line Items
Step 3: System links to child taible
The system creates or connects to a child taible. This child taible is a separate, full-featured taible.
The system creates or links to a child taible:
Step 4: Add child rows
Child rows are created automatically when the parent column runs, or you can add them manually in the child taible.
Child rows are created (automatically by column or manually):
| Product | Qty | Price |
|---|---|---|
| Product A | 2 | $10 |
| Product B | 1 | $20 |
| Product C | 3 | $15 |
Step 5: Sub-taible cell shows count
The parent cell displays how many child items exist.
| Order ID | Customer | Date | Order Items |
|---|---|---|---|
| #1001 | John | Oct 24 | 3 Entries |
Navigating the Relationship
Parent View: Orders Taible
| Order ID | Customer | Order Items |
|---|---|---|
| #1001 | John | 3 Entries |
2. Click arrow button to navigate
Child View: Order Line Items (filtered to Order #1001)
| Product | Quantity | Price |
|---|---|---|
| Product A | 2 | $10 |
| Product B | 1 | $20 |
| Product C | 3 | $15 |
Use back button or breadcrumb to return
From parent view:
- See parent row with sub-taible cell
- Hover over the sub-taible cell to reveal arrow button
- Click the arrow button (square with arrow pointing up-right)
- Navigate to child taible view (automatically filtered to parent's children)
- See only children of that parent
- Breadcrumb in the header shows parent context (e.g., "Orders / order_items")
From child view:
- See child rows (filtered by parent)
- Breadcrumb shows parent context in the format: "Parent Table Name / Column Label"
- Use browser back button or click breadcrumb to return to parent taible
- Can also navigate directly to see all child rows (without parent filter)
Accessing Parent Data in Children
Children can use parent data:
When configuring child columns, you can set up dependencies to access parent taible data. The system provides an autocomplete that helps you select parent columns.
Example: A child column can automatically show:
- Customer name from parent order
- Shipping address from parent order
- Order date from parent order
- Any other parent column value
The data flows automatically—no manual copying needed!
Combining Child Data in Parents
Parent can gather data from all children:
Using the Pull Data column type, you can:
The Pull Data column retrieves all values from a specific column in the child taible.
What you get:
- • An array of all values from that column
- • Example: [20, 45, 30, 15] for line totals
What you can do with it:
- • Use another column to sum, average, count, etc.
- • Transform the data as needed
- • Display aggregated results in parent
Common combinations:
- Sum all values: Add up totals, quantities, amounts
- Count items: How many children exist
- Average values: Calculate averages across children
- Find highest/lowest: Get maximum or minimum values
- Combine text: Join descriptions or notes
- Check completion: Count how many are done
Example: Project Completion
Sub-Taibles vs. Alternatives
When NOT to Use Sub-Taibles
Use Case: Related but Independent Entities
Example: Customers and Orders
Wrong approach:
Using sub-taibles for customers → orders is not ideal because:
- Orders are significant entities that can be queried independently
- Orders have their own lifecycle
- Orders are not "owned by" customer in the sense of being deleted when customer is deleted
Better approach:
Create two separate taibles:
- Customers Taible with customer information
- Orders Taible with order information
- Link them using a "customer_id" column in Orders
Use linking columns instead of sub-taibles when:
- Both entities are equally important
- You need to query both independently
- Relationship is reference, not containment
When TO Use Sub-Taibles
Use sub-taibles when:
- Children only make sense in context of parent
- Children are "owned by" or "part of" parent
- Primarily view children through parent
- Children share parent's lifecycle (delete parent = delete children)
Examples where sub-taibles are perfect:
- Order → Line Items (items don't exist without order)
- Email Thread → Messages (messages are part of thread)
- Invoice → Line Items (lines don't exist without invoice)
- Project → Tasks (in this context, tasks are project-specific)
Sub-Taible Patterns
Pattern 1: Detail Records
Master-detail relationship
Structure:
- Master: Order (summary information)
- Detail: Line Items (granular information)
Data flow:
- User creates order (master)
- System creates line item rows (detail)
- Line items process individually
- Results combine back to master
Pattern 2: Timeline/History
Parent with historical records
Structure:
- Parent: Customer
- Children: Purchase History (timestamped)
Data flow:
- Customer exists
- Each purchase creates child row
- Child rows accumulate over time
- Parent shows: "15 purchases" or latest purchase date
Pattern 3: Decomposition
Break complex data into manageable pieces
Structure:
- Parent: Complex Report
- Children: Report Sections
Data flow:
- Trigger creates report (parent)
- Creates child row for each section
- Each section processes independently (fetch data, generate charts, format)
- Parent gathers: All sections done → Report complete
Pattern 4: Multi-step Processing
Each child is a processing step
Structure:
- Parent: Batch Job
- Children: Individual Items to Process
Data flow:
- Batch created with 1000 items (parent)
- Create child row per item
- Each child processes independently
- Parent tracks: "850/1000 complete (85%)"
Real-World Examples
Example 1: E-commerce Order System
E-Commerce Example
Interactive example component
Parent Taible: Orders
- Columns: Order ID, Customer Name, Customer Email, Order Date, Status, Order Items (sub-taible), Order Total, Shipping Label
Child Taible: Order Line Items
- Columns: Product Name, Product SKU, Quantity, Unit Price, Line Total, Inventory Status, Tracking Number
Workflow:
- Shopify webhook creates order (parent row)
- Webhook data includes line items array
- System creates child row for each line item
- Child columns process:
- Check inventory
- Reserve stock
- Calculate line total
- Parent columns gather results:
- Sum line totals → order total
- Check all items in stock → update status
- Parent columns act:
- Generate shipping label
- Send confirmation email
Example 2: Support Ticket System
Parent: Support Tickets
- • Ticket ID
- • Customer Email
- • Subject
- • Status
- • Priority
- • Messages (sub-taible)
- • Last Response Date
- • Resolved
Child: Ticket Messages
- • Message Body
- • Sender (customer or agent)
- • Timestamp
- • Sentiment
- • Auto Response
Workflow:
- Email trigger creates ticket (parent row)
- Email content becomes first message (child row)
- AI analyzes sentiment and drafts auto-response
- Each reply creates a new message (child row)
- Parent tracks message count and last response date
Parent Taible: Support Tickets
- Columns: Ticket ID, Customer Email, Subject, Status, Priority, Messages (sub-taible), Last Response Date, Resolved
Child Taible: Ticket Messages
- Columns: Message Body, Sender (customer or agent), Timestamp, Sentiment, Auto Response
Workflow:
- Email trigger creates ticket (parent row)
- Email content becomes first message (child row)
- AI analyzes message sentiment
- Auto-response drafted (child column)
- Agent reviews, sends response (creates new child row)
- Customer replies (email trigger creates new child row)
- Parent shows: "5 messages" and last response date
- When resolved, parent status updates
Example 3: Project Management
Parent: Projects
- • Project Name
- • Deadline
- • Owner
- • Tasks (sub-taible)
- • Completion Percentage
- • Overdue Tasks Count
Child: Tasks
- • Task Name
- • Description
- • Assigned To
- • Due Date
- • Status
- • Hours Estimated
- • Overdue Alert
Workflow:
- Create project (parent row)
- Add tasks (child rows)
- Each task sends notifications and tracks status
- Parent calculates completion % from done tasks
- Parent sends weekly status report
Parent Taible: Projects
- Columns: Project Name, Deadline, Owner, Tasks (sub-taible), Completion Percentage, Overdue Tasks Count
Child Taible: Tasks
- Columns: Task Name, Description, Assigned To, Due Date, Status, Hours Estimated, Hours Actual, Overdue Alert
Workflow:
- Create project (parent row)
- Manually add tasks (child rows)
- Each task has:
- Assignment notification (when someone is assigned)
- Overdue alert (scheduled check)
- Status tracking
- Parent gathers:
- Count done tasks / total tasks = completion %
- Count overdue tasks
- Parent sends weekly status report
Key Concepts Summary
Before learning the UI, make sure you understand:
What sub-taibles are: Separate tables linked through parent-child relationship
When to use them: One-to-many relationships where children "belong to" parent
Architecture:
- Parent taible with sub-taible column
- Child taible linked to parent
- Two separate tables, connected
Data flow:
- Parent → Child: Children can reference parent data automatically
- Child → Parent: Parent gathers child data using Pull Data columns
Independence: Children have full automation capabilities (triggers, columns, conditions)
Navigation: Hover over cell → Click arrow button → View children; breadcrumb → Return to parent
Use cases:
- Collections (order items, invoice lines)
- History (interactions, purchases)
- Composition (recipe ingredients, BOM components)
- Multi-step processing (batch jobs)
The Power of Sub-Taibles
Without sub-taibles:
- Flatten data (lose structure)
- Duplicate parent data across rows
- Complex workarounds
- Limited automation
With sub-taibles:
- Natural data modeling
- Clean parent-child separation
- Independent child automation
- Easy data combination
- Intuitive navigation
- Scalable (handle 1 or 1000 children)
Real impact:
- Order with 50 line items? No problem.
- Customer with 500 purchases? Easy to track.
- Project with 100 tasks? Each automated independently.
Next Steps
You understand what sub-taibles are and when to use them. Section 7.2 will show you:
- How to create sub-taible columns (step-by-step UI)
- Converting existing data to sub-taibles
- Two methods: Convert collection or create new
- Adding and managing child rows
- Configuring parent-child data flow
Let's build sub-taibles!