7.3 Working with Sub-Taibles

You've created sub-taibles and understand how they're structured. Now let's put them to work! This section shows you how to navigate between parent and child taibles, add and manage data, and create powerful automations that span both levels.

Viewing Your Sub-Taibles

Seeing Child Row Counts

When you're viewing a parent taible, the sub-taible column shows you how many child rows each parent has:

Orders

Order ID	Customer	Order Items	Total
1001	John Smith	3 Entries	$95
1002	Sarah Johnson	5 Entries	$280
1003	Mike Chen	0 Entries	$0

Hover over a sub-taible cell to see the navigation button appear (→)

What you see:

• A badge showing the count (like "3 Entries" or "5 Entries")
• A navigation arrow (�) that appears when you hover over the cell
• Different badge colors: blue for rows with children, gray for empty

Navigating to Child Rows

To view a parent's children:

1. Hover over the sub-taible cell (where the count badge is)
2. Click the arrow button (�) that appears
3. The child taible opens, filtered to show only that parent's children

|Parent: Order #1001

Order Line Items

Product	Quantity	Unit Price	Line Total
Product A	2	$10.00	$20.00
Product B	1	$20.00	$20.00
Product C	3	$15.00	$45.00

All 3 entries shownFiltered to parent: Order #1001

What happens:

• The browser navigates to the child taible
• You see breadcrumb navigation showing where you are
• Only rows belonging to this parent are shown
• You can add, edit, or delete child rows
• Use the back button or breadcrumb to return to the parent

Navigation Tip

The URL updates to include ?parentRow=123 which filters the child taible. You can bookmark these URLs to jump directly to specific parent-child views!

Adding Child Rows

There are two ways to add new child rows to a parent.

Method 1: Navigate Then Add

This is the most common approach:

Steps:

1. Click the arrow button (�) in the parent's sub-taible cell
2. Click the "+ Add" button in the child taible toolbar
3. Enter the data for your new child row
4. Press Enter or Tab to save
5. Click the back button or breadcrumb to return to the parent

The new child is automatically linked to the parent you navigated from!

Method 2: Direct Creation

If you're already viewing the child taible (not filtered by parent):

1. Click "+ Add" to create a new row
2. The system asks which parent to link it to
3. Select the parent from the dropdown
4. Enter the rest of the data

Important

If you create a child row without specifying a parent, it becomes "orphaned" and won't show up when viewing any parent's children. Always link children to parents!

Accessing Parent Data in Children

One of the most powerful features: child rows can "see" and use data from their parent row.

Child Rows Can Access Parent Data

Each line item can pull information from its parent order

Product	Customer From Parent	Ship To From Parent	Order Date From Parent
Product A � 2	John Smith	123 Main St, Seattle, WA	Oct 24, 2024
Product B � 1	John Smith	123 Main St, Seattle, WA	Oct 24, 2024
Product C � 3	John Smith	123 Main St, Seattle, WA	Oct 24, 2024

How it works: Configure the child column's dependencies to include parent columns. The system automatically pulls data from the parent row.

How to Set This Up

In the child taible:

1. Add or edit a column that needs parent data
2. Open the Run Configuration section
3. Click "Add Dependency"
4. Choose columns from the parent taible
5. The system automatically pulls that data from the parent row

Example use cases:

• Shipping labels: Each line item needs the customer's address (from parent order)
• Task assignments: Each task shows the project name (from parent project)
• Invoice details: Each line item includes the customer's payment terms (from parent invoice)

What You Can Access

From a child row, you can reference:

•  Any column in the parent taible
•  Parent's manually entered data
•  Parent's calculated data
•  Parent's AI-generated content

The system handles it all automatically - just set up the dependencies!

Aggregating Child Data to Parent

Now let's go the other direction: pulling data from children back up to the parent.

Parent column: "Order Total"

Configuration:

• • Type: Pull Data
• • Source Taible: order_items (the sub-taible)
• • Source Column: line_total

Process:

1. Pull Data retrieves all line_total values: [$20, $20, $45]
2. Use a Transform or Custom Code column to sum them
3. Result: $85 total

Using Pull Data Columns

Pull Data columns are designed for this. Here's how:

In the parent taible:

1. Add a new column (type: Pull Data)
2. Source Taible: Select your child taible
3. Source Column: Select which child column to pull from
4. Filter by Parent: Leave enabled (this is the default)

What happens:

• The Pull Data column automatically filters to only this parent's children
• It pulls the values from all matching child rows
• You get a list of values back

Common Aggregations

To calculate totals, averages, counts, etc.:

1. First, use Pull Data to get the child values (as shown above)
2. Then add another column (type: Transform or Custom Code)
3. Perform the calculation on the pulled data

Example: Order Total

Column 1 (Pull Data): "line_totals"

• Pulls line_total from all child line items
• Result: [20, 20, 45]

Column 2 (Transform): "order_total"

• Depends on "line_totals"
• Uses a SUM operation
• Result: 85

Automatic Updates

If you set the parent column to run mode "Always," it recalculates whenever children change. Your totals and summaries stay in sync automatically!

Deleting Rows

Deleting Child Rows

This is simple:

• Delete a child row just like any other row
• Only that child is deleted
• The parent remains unchanged
• Other children are unaffected

Deleting Parent Rows

This requires a decision: what happens to the children?

Delete Order #1001?

This order has 3 child items

What should happen to child rows?

Delete children (recommended)

• 3 line item rows will be permanently deleted
• This cannot be undone
• Clean removal with no orphaned data

Keep children (orphaned)

• Line items will remain but have no parent
• They may appear in "all items" view
• Not recommended

When you delete a parent row, you'll see this dialog with two options:

Option 1: Delete Children (Recommended)

What happens:

• The parent is deleted
• All child rows are deleted
• Clean removal with no orphaned data
• This is usually what you want

Use when:

• You're done with both parent and children
• You want a complete removal
• You're cleaning up test data

Option 2: Keep Children (Orphaned)

What happens:

• The parent is hidden (soft deleted)
• Children remain in the database
• Children become "orphaned" (no parent link)
• They may appear in "all rows" views

Use when:

• You might restore the parent later
• The children have value independent of the parent
• You need to maintain a historical record

Caution

Orphaned children can be confusing! They won't show up when you navigate from a parent (because there's no parent), but they're still in the system. Most users should choose "Delete Children" to keep things clean.

Building Workflows with Sub-Taibles

Let's see how to create automation that flows between parents and children.

Pattern 1: Parent Triggers Children

Example: E-commerce Order

Parent taible: Orders

1. Webhook receives order � Creates parent row
2. Parent extracts line items � Populates sub-taible column with array
3. System creates child rows automatically (one per item)
4. Children process independently:
   • Check inventory
   • Reserve stock
   • Calculate shipping
5. Parent aggregates results � Total, shipping weight, status

The power: One webhook triggers a cascade of automated child processing!

Pattern 2: Children Update Parent

Example: Project Management

Child taible: Tasks (with status: To Do, In Progress, Done)

Parent taible: Projects

• Pull Data column: Pulls all task statuses from children
• Calculation column: Counts "Done" vs Total � Completion percentage
• Status column: Updates project status based on tasks
• Notification column: Emails manager when all tasks complete

The power: Parent status automatically reflects what's happening in children!

Pattern 3: Conditional Processing

Example: Quality Control

Parent: Incoming Orders

• Status column: "approved" or "pending"

Children: Line Items

• Condition on every column: Only runs if parent status = "approved"
• Result: Children only process for approved orders

The power: Parent controls whether children run at all!

Navigation Tips

Using Breadcrumbs

At the top of every child taible view:

Orders > Order #1001 Items
  �           �
  |           � Current view
  � Click to go back to parents

Click any level to jump back up the hierarchy.

Keyboard Shortcuts

• Browser back button or Alt + � (Windows) /  + [ (Mac): Go back to parent
• Browser forward if you went back

Bookmarking

You can bookmark specific parent-child views:

Parent view:

/taibles/orders_table_id

Specific parent's children:

/taibles/order_items_table_id?parentRow=1001

This lets you create quick links to frequently viewed sections!

Real-World Example: Support Ticket System

Let's see it all come together with a complete example.

Structure

Parent Taible: Support Tickets

• Columns: ticket_id, customer_email, subject, status, messages (sub-taible), message_count, last_reply_date

Child Taible: Messages

• Columns: message_body, sender, timestamp, sentiment_analysis

Workflow

1. Email arrives �

• Creates parent ticket row
• Extracts subject, sender
• Creates first child message

2. AI processes message �

• Classifies ticket (Bug, Feature Request, Question)
• Analyzes sentiment (Happy, Neutral, Frustrated)
• Generates draft response

3. Agent reviews and responds �

• Views parent ticket
• Clicks into messages (children)
• Sees all messages in the thread
• Sends response (creates new child message)

4. Customer replies �

• System finds existing ticket by subject
• Creates new child message
• Parent's "last_reply_date" updates automatically
• Parent's "message_count" increments

5. Manager views dashboard �

• Sees all tickets
• Each shows message count and status
• Can click into any ticket to see full thread

The power:

•  Complete conversation history (children)
•  Ticket metadata and status (parent)
•  Automatic aggregations (message count, latest date)
•  Easy navigation between views
•  Full automation of classification and routing

Best Practices

 Do This

1. Use descriptive sub-taible column names

   • L "items"
   •  "order_items" or "line_items"

2. Always delete children when deleting parents (unless you have a specific reason not to)

3. Set up parent data access explicitly

   • Don't assume children can see parent data
   • Configure dependencies in Run Configuration

4. Use Pull Data + calculation pattern for aggregations

   • Pull Data gets the child values
   • Transform/Custom Code performs the math

5. Let the system filter for you

   • Pull Data automatically filters by parent
   • Don't try to filter manually

L Avoid This

1. Don't create orphaned children

   • Always link children to parents
   • Choose "Delete Children" when removing parents

2. Don't manually manage parent-child links

   • Let the system handle the relationship
   • Use the navigation buttons, not manual IDs

3. Don't forget to set dependencies

   • If children need parent data, configure it
   • The system won't assume relationships

4. Don't create circular dependencies

   • Parent depends on child � 
   • Child depends on parent � 
   • But not both for the same calculation! � L

Troubleshooting

Child rows not showing up

Check:

• Are you viewing with the ?parentRow= filter?
• Was the child linked to the correct parent?
• Is the child row actually created? (Check "all rows" view)

Parent data not accessible in child

Check:

• Did you add parent columns to child column's dependencies?
• Is the dependency configuration saved?
• Are both parent and child columns running?

Aggregations not updating

Check:

• Is the parent column set to run mode "Always"?
• Is the Pull Data column actually running?
• Does the parent column depend on the Pull Data column?

Navigation button not appearing

Check:

• Are you hovering over the sub-taible cell?
• Does the column type show as sub-taible?
• Is there a child taible configured?

Summary

You now know how to:

 Navigate between parent and child taibles using hover buttons  View filtered child rows for specific parents  Add child rows that are automatically linked to parents  Delete parent rows with choices about children  Access parent data from child rows using dependencies  Aggregate child data back to parents using Pull Data  Build automation workflows that span parent-child relationships  Troubleshoot common issues with sub-taibles

The power of sub-taibles:

• Organize complex, hierarchical data naturally
• Build workflows that cascade from parent to children
• Aggregate and summarize child data automatically
• Navigate your data structure intuitively
• Keep related information together without duplication

Next steps:

• Try creating a simple parent-child workflow (like orders and line items)
• Experiment with aggregating child data back to parents
• Build automation that flows between levels
• Explore conditional processing based on parent status

Sub-taibles transform flat data into organized, automated systems. Start simple and build up!