Help

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

Generalize multi-valued types

cancel
Showing results for 
Search instead for 
Did you mean: 
Carlos_Pita
5 - Automation Enthusiast
5 - Automation Enthusiast

There are some feature requests here that can be generalized by this feature:

Allow typed lists fields. That is, fields that are a list of values of some type. For example, multiple checkboxes, multiple urls, etc.

Currently just a few types accept multiple values: selects, attachments and links to other records. Why not make this more consistent: every type can be single or multiple, that is a restriction on cardinality orthogonal to the type itself.

I understand this is a bit at odds with modelling one to many relationships between tables, but it’s very convenient for simple fields (you already recognized it by providing multiple attachments and selects) and avoid having to cascade delete or removing orphans after deletion.

5 Comments
BenInDallas
7 - App Architect
7 - App Architect

This would be SO very useful. My company’s project mgmt base currently lacks a useful way to add ongoing notes on projects (which could easily be facilitated by a multi-value text field), and expense tracking (a multi-value number field), and to-do items (a multi-value checklist).

It is somewhat related to my previous post about Nested Tables:

But your idea would probably be much easier to implement, and would solve (at least) some of the simpler issues that mine was trying to address.

Julian_Kirkness
10 - Mercury
10 - Mercury

Hi

In any relational database (like Airtable) the way to achieve this is with related ‘child’ tables containing, for example, a dated history of contacts or expenses.

In my view, Airtable need to do a little work on their UI to make working with relational data a bit more intuitive - but if you use expanded view in the main parent record it’s a lot better than the table view. I would actually love to see a setting for a table that records could ONLY be added or edited in expanded view because I feel the risk of error with the ‘spreadsheet like’ UI is too great.

Julian

BenInDallas
7 - App Architect
7 - App Architect

Hi Julian. The “child” tables you’re describing might be the same thing I’m describing with a “Nested Table”.

In any case, I totally agree that a better interface could help solve a lot of problems. In particular, the display of linked records (in every view mode) is horrible. We need to have full control of which fields are displayed on each linked record, how they are sorted, filtered, color-coded, etc.

Julian_Kirkness
10 - Mercury
10 - Mercury

I quite agree - especially as people are wanting to build more and more complex solutions with Airtable (which is a natural effect of time - solutions grow).

Things are a bit better in Expanded view - but even here it gets confusing and you have no control about what you see. I am also very unhappy with the fact that to add a new sub record you are first asked whether you want to connect an existing one - which by definition will be already connected to a different parent record and it should really be impossible to connect it to another!!!

Airtable either don’t really understand relational databases or are excessively worried about moving away from the spreadsheet like paradigm. The problem is that Spreadsheets have always made terrible databases and the UI just isn’t suitable for some things.

I do hope, one Blocks are finished, that Airtable moves on to look at the UI and data integrity in respect of relational data!

Having said that I really like Airtable and so do my customers as it’s very visual.

Back to the OP of this thread, I would strongly recommend against providing multi value fields - it’s just about acceptable with Multi Select fields although I would prefer to use Linked Tables here as well if there were the same features.

Prefabberghaste
4 - Data Explorer
4 - Data Explorer

The problem I’m having is that the values I need to have in the field are different for each record. So a child table would be HUGE. And each value may only be used once.

I am trying to track scope items in contracts. I would like to list each task, and be able to identify which have been completed. Each contract has different scope items/tasks, so it doesn’t make sense to make another table of these items. Also there is not a set number of tasks, so I can’t set up fields like task 1, task 2, etc.

A simple checklist where I can also link each task to an invoice and payment for that task would be great. Right now I’m just using a list in Long Text.