# Hierarchical Table records **URL:** \ **Category:** Product Suggestions\ **Created:** [December 19, 2024, 7:50pm UTC](https://community.tulip.co/t/hierarchical-table-records/13409 "2024-12-19T19:50:27Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![rcanaway](https://avatars.discourse-cdn.com/v4/letter/r/6a8cbe/32.png) [@rcanaway](https://community.tulip.co/u/rcanaway)\ **Post date:** [December 19, 2024, 7:50pm UTC](https://community.tulip.co/t/hierarchical-table-records/13409/1 "2024-12-19T19:50:27Z")
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 ---
**Author:** ![Beth](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/beth/32/5987_2.png) [@Beth](https://community.tulip.co/u/Beth)\ **Post date:** [December 23, 2024, 4:32pm UTC](https://community.tulip.co/t/hierarchical-table-records/13409/2 "2024-12-23T16:32:57Z")
Hi @rcanaway - Thanks for your question and welcome to Tulip Community 🎉 🌷 A couple considerations here: - You can use [linked records](https://support.tulip.co/docs/linking-table-records) within a single table to accomplish these parent-child type relationships - a limitation of linked records is that they cannot be used in queries and aggregations (You can do a workaround as suggested here [Allow Table Queries to Filter Over Linked Record Fields](https://community.tulip.co/t/allow-table-queries-to-filter-over-linked-record-fields/6253)) - 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?](https://community.tulip.co/t/reflexive-linked-record/11371)) 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 🙂 ---
**Author:** ![Preston](https://avatars.discourse-cdn.com/v4/letter/p/a587f6/32.png) [@Preston](https://community.tulip.co/u/Preston)\ **Post date:** [December 26, 2024, 11:19pm UTC](https://community.tulip.co/t/hierarchical-table-records/13409/3 "2024-12-26T23:19:29Z")
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. 🕶