Hierarchical Table records

Product Suggestions
1

Hi,
I’m interested in creating a hierarchy in table records, such as an overall purchase order (parent record) with child records specifying which products are applicable to that specific order.
Is this functionality currently available, or is it planned for a future update? If possible, could you share insights or workarounds for implementing this?

Example:
Parent Record:

  • Child Record
    • More Information
  • Child Record
    • More Information
2

Hi @rcanaway -

Thanks for your question and welcome to Tulip Community :tada: :tulip:

A couple considerations here:

  • You can use linked records within a single table to accomplish these parent-child type relationships
  • You could also consider a table structure where each row is unique (ex. Parent 1, Child 1, More Info; Parent 1, Child 2, More Info, etc.)
    • this type of structure would rely on uniqueID for tracking each parent-child combo and could use queries and aggregations
  • That being said, it is worth reading this thread here (Reflexive Linked Record?) to see @giladl’s recommendation:
    “We recommend that there is a table for every level or type of assembly or component. For example a “Devices” table that is linked to an “Assemblies” table that is linked to a “Sub Assemblies” table that is linked to a “Components” table. In this way anybody either with or without Tulip experience can immediately understand and use the data.”

@jasonh and @Preston may have some god insights here as both of them have navigated table hierarchy within Tulip tables as well.

As for make this natively easier within Tulip to manage these type of parent-child relationships within a table, our Product Team is aware of this and has some longer term work that should make it easier, but I don’t have any details on that yet, as it is still a ways away due to other priorities on our roadmap!

Hope this helps :slight_smile:

3

Thanks for the mention Beth.

@rcanaway, welcome. I believe that the best way to do this is through multiple tables, as Beth suggested.

As an example, this is how we deal with outbound orders. We have three tables, which follow a hierarchy.

  1. Shipping Orders
  2. Shipping Details (many SD map to one SO)
  3. Shipping Executions (one SE maps to one SD)

Shipping Orders contains information such as the Shipping ID, Customer, Completion Status, Operator that shipped the order. This is the high-level order.

Shipping Details contains a random-generated ID, the Shipping ID, Product Code, Quantity. This is the line number level, where products for the order are specified.

Shipping Executions contains a random-generated ID, the Shipping ID (or Shipping Details ID), Serial Number. This is where individual units are allocated to a Shipping ID and/or Shipping Details ID.

A practical example of this in action:

Shipping Orders
Shipping ID Customer Completed Status Shipped By
SO000001 Peter Yes Matt
Shipping Details
ID Shipping ID Product Code Quantity
dgnMVAB2keQj622au SO000001 100100 25
UjmEg5mJ8o6ch8Rk4 SO000001 100101 30
Shipping Executions
ID Shipping ID Shipping Details ID Serial Number
HeC9cFz8y54sbVsj5 SO000001 dgnMVAB2keQj622au 1000000000000000001
DPsxcSU7dy62Ex5sp SO000001 dgnMVAB2keQj622au 1000000000000000002
woXYEuTD9cNW6v3B6 SO000001 dgnMVAB2keQj622au 1000000000000000003
Z8NA9RY4urZw6rdQD SO000001 dgnMVAB2keQj622au 1000000000000000004
nHBrFzpnp37XTJ4Q6 SO000001 UjmEg5mJ8o6ch8Rk4 1000000000000000005
7XWooFgsUMEw7Bi52 SO000001 UjmEg5mJ8o6ch8Rk4 1000000000000000006

Use table queries and aggregations to fully capitalise on this table structure. Good luck, and have fun. :sunglasses: