Help

This Product Ideas board is currently undergoing updates, but please continue to submit your ideas.

New Field Type: Nested Table

cancel
Showing results for 
Search instead for 
Did you mean: 
BenInDallas
7 - App Architect
7 - App Architect

As weโ€™ve been testing AirTable for our businessโ€™s project management needs, one thing weโ€™ve had trouble setting up is something like an expense report, purchase order, or mileage report.

Our typical reports would be a single printable document with several standard pieces of data (job name/number, purchase date, vendor info, billing method, etc), and a table containing purchase info (item, qty, price) with totals at the bottom.

In Airtable, you can currently accomplish something like this with two tables (letโ€™s call them โ€œExpense Reportsโ€ and โ€œExpense Itemsโ€) with the latter connected to the former with a โ€œLinkโ€ field. But itโ€™s a bit clumsy, because youโ€™d have one table with each โ€œreportโ€ and another table that contains lots and lots and lots of expense items that likely have nothing to do with each other. More importantly, itโ€™s not really possible to export the data from each Report while including the Expense Item data.

A more elegant solution would be a field type called โ€œNested Table.โ€ This would create (within a record) a small table/spreadsheet with customizable columns, simple math functions, and the ability to add rows on-the-fly.

Thoughts?

28 Comments
Conrad_Lindes
5 - Automation Enthusiast
5 - Automation Enthusiast

I worked for over 20 years with a product called Alpha4, which was a desktop application based on the .dbf file structure. That was a โ€œrelationalโ€ database in that I could create reports that could โ€œnestโ€ an unlimited number of sub-items, sorted on any major item I chose, and print out not just the result for one record at a time, but for the whole list of records. When this went to Alpha5, which is the on-line version, it got less and less user friendly, which is what got me interested in finding an online alternative that was easier to work with. So far, Airtable has a long way to go. I hope the team works on this nesting and gets it right soon.

BenInDallas
7 - App Architect
7 - App Architect

Conrad, youโ€™re the second person Iโ€™ve heard sing the praises of that older product. Please let me know if you find anything comparable!

Steffan_Andrews
4 - Data Explorer
4 - Data Explorer

Iโ€™m also seeking this functionality, and itโ€™s what will make or break Airtableโ€™s usefulness for my current needs.

David_Craig
4 - Data Explorer
4 - Data Explorer

You might want to check out Obvibase, it is limited in functionality, but does have a pretty good implementation of this feature.

Andrey_K
4 - Data Explorer
4 - Data Explorer

This feature will be really game changer for the Airtable. For sales pipeline we may create nested tables of products and their qty as a commercial proposal or create list of components for something etc.

We definitely need this new field type.

UPD. This example https://support.airtable.com/hc/en-us/articles/218734758-A-beginner-s-guide-to-many-to-many-relation... may be make easier with nested table field!

Brett_Garwood
5 - Automation Enthusiast
5 - Automation Enthusiast

Yep, have needed this for quite some time. I need it to manage sub tasks of a primary task of a project plan.

Ryan_Lavalley
5 - Automation Enthusiast
5 - Automation Enthusiast

This would be a super helpful feature for multiple of my projects. +1 from me.

Helen_Vaskevitc
5 - Automation Enthusiast
5 - Automation Enthusiast

I have run into the need for this exact functionality on multiple projects, so far the only workaround Iโ€™ve found is having many many fields to hold all the sub-data I need for each record, itโ€™s quite clunky.

My projects where Iโ€™ve wished for this functionality are:

Example 1:
I work at a theater production company, and I have created a base that keeps track of every person we have ever hired or interacted with or submitted a show to for production. This includes actors, producers, directors, musicians, etc etc. Some people have participated in multiple shows, playing a different role in each show. A person might play drums in show โ€œAโ€, and might play the part of Mary in show โ€œBโ€. I want all this information stored in the record for that person. My workaround is to have a new field for every production of every show, which lists what role a given person played in that show. A run of a show may have 6 shows/week for 4 weeks. So, that run alone, of that single show, would add 24 fields to my People table.

Example 2:
I also work for a musician, and Iโ€™ve created a base that keeps tracks of every song he co-writes, to keep track of publishing splits. A song may have 3 co-writers, and each of those co-writers has a publisher, some of the writers might have 2 publishers, and then some of them might have admins as well. So, a single song may have, say, 9 entities who each need to be paid when a song is used. I canโ€™t just list all the writers in one field and all the publishers in one field, because I need to know the relationship of which publisher goes with which writer. And I canโ€™t just list this relationship in a separate Writers tab, because the writer may change publishers from year to year, and I need to be able to see which publisher they were with for that particular song. So, to keep track of it all, in the songs tab I have a field for writer 1, 2, etc, a field for publisher 1, 2, etc corresponding to writer 1, 2, a field for admin 1, 2, and then a separate field for each entityโ€™s split. Thatโ€™s a whole lot of fields! It almost necessitates a separate tab for each song, but with 400+ songs, that is completely non-feasible. Hence, the need for subtables.

Using the many fields workaround creates another problem, in that, when I list โ€œwriter 1โ€ โ€œwriter 2โ€ etc, and link that to the writers table, in the writers table there are now multiple fields which list songs written by that writer, because I had to have separate fields for each writer on a particular song, when really all the songs written by a single writer should be listed in one single field. I can make some kind of summing field to collect all this data in one place, but the original set of multiple fields still has to exist, and again, itโ€™s pretty clunky.

So yes, a field type called table would be helpful, and also, if anyone has any suggestions for me on how to make either of these bases more efficient I would love to hear them!

Randi_Leist
4 - Data Explorer
4 - Data Explorer

Desperately trying to find a solution such as this. I love Airtable but, I need a way to create an invoice worksheet for our operations department to build a worksheet and donโ€™t want to use another software for it. Iโ€™d rather it all be in Airtable. Really hoping this functionality is brought to airtable.

Elias_Gomez_Sai
13 - Mars
13 - Mars

This is wrong. You need a junction table for Roles (or similar), to store Person, Show, and details like Character, Payment, and so on. You can create Views, Filers, Groupsโ€ฆ to see the information you want.

The same for example 2, you just need extra tables for people, and of course for the Roles. I would have:

  • Songs
  • Writings
  • Publishing
  • Admin
  • People

Then build relations with Linked Record fields. Example:

  • Writing: Song, Person (from People), and details