Filtered Look-Up list influenced from same record field entry

There has long been a desire for dependencies between pick lists.

I think On2Air has one solution when using a form.

If you have only one user at a time picking for only one record at a time, you can use a system of roll ups and a filtered view to accomplish this. I believe @Justin_Barrett and @W_Vann_Hall and I all have systems like this.

Finally, if picking the records in the second linked record field is done in scripting block, this is quite doable.

@Karlstens Be sure to email support@airtable.com to request this… they don’t seem to understand the importance of this much-needed feature.

There is a workaround to this dilemma here, but it comes with its own set of limitations & challenges:

I came here to say how much I appreciate the Willy Wonka candy example base with related emojis!! :grinning_face_with_smiling_eyes:

I have to create example data on a regular basis. My last one was Marvel/DC Characters characters - Captain America, Iron Man, Wonder Woman, Superman, etc. :woman_superhero:

And yes, dependencies per field would be great!

As @kuovonne stated, it is possible using On2Air Forms. Here’s an example: How to Create Custom Forms Showing Filtered Records in Airtable

Thanks for your kind words everyone, and glad that I hadn’t missed anything obvious and that this issue still stands. @Hannah_Wiginton you’re free to expand on my Willy Wonka demo theme too .

For the short-medium term, I guess I’ll see if I can work on a Script applet that allows for data entry via a filtered lists system - Although I suspect I’m not at the stage needed for writing such an app (and in all honesty I still have my Look-Up Fields MarkDown Text Roll-Up project that I need to push forwards with, as that’s something I KNOW I can code, just need time + motivation)

Regardless, I’ve reached out to Airtable Support regarding this thread, honestly I think this limitation needs to be on top of their list - especially now Interfaces are a thing and more and more users are using Interfaces for data entry, filtered lookup fields will be absolute magic to have within the Interface environment - I’d even go as far to say that I would be OK if this feature only existed via Interfaces but not within the Base itself (although realistically it would be best if it was in both the base and interface).

It’s worth noting, that even with this current limitation of unfiltered Look-ups, I pushed on with this database idea (and make no mistake, having to deal with unfiltered look-ups is very much a real problem) to find the potential that lay under-the-hood of such base design. And to my surprise I discovered this.

"\\"" & LEFT(ARRAYJOIN({Methodology Index Codes},"  "),(FIND(",",ARRAYJOIN({Methodology Index Codes},",")))-1) & "\\"," & ARRAYJOIN({Code Order Rollup}, " & ")

This one line of code is what blew my mind, when I realised that not only can Airtable be used to design product methodology (be it for Candy, or umbrellas, or Volvos, what ever) - but once the structure is in place it gives users the ability to write code-generating formula fields. But then… This lead to another bug-bear that many of us have witnessed and complained about previously - Linked-Field Field Entry Order.

Perhaps a Candy methodology should be, Flavour then Colour… or no, it should be Colour, then flavour! What ever it is, unfortunately, the more complex the methodology, the more Airtable makes this task manual and laborious.

Note the restructure in the Base by the Ompa-Loompas, for instead of a separate Flavour table and a Colour table, they’ve now been both rolled up into a “Global Fruity Index” table.

All Colours and Flavours created in the one index and mapped to “Type”. And it’s worth noting that here is where users will find real power to Airtable Views, as a “Colour” view can be created, and a “Flavour” view created, and then the pick-lists in the Candy Code creator table can be limited to those very lists, but this then swings back to the original problem of this base, the View pick-lists can’t be field-dependant filtered, such as filtering by a theme. But I digress, back to this secondary issue I’m hi-lighting.

Eventually, with a bit of remapping each methodology of every product can be setup dynamically - which is freakin’ amazing!!! … but with one huuuuge draw back - the order of each methodology (assuming they’re unique for each product - because of “reasons”) can only be adjusted manually through a drag and drop process.

All the fancy Airtable views that can programmatically address order within the Index table are simply ignored when it comes to the structure needed within the Methodology, and the user/developer is left with this…manually, god-forsaken process of dragging and dropping each individual entry, over and under, and under and over, ad nauseam - Too much candy perhaps? ( ͡~ ͜ʖ ͡°).

Now this is not such a big deal for a methodology that consists of 2 index, a flavour and a colour… but… in the real world - right now I’m looking at a list of 200 indexes across 200 unique products… and growing!

Airtable devs, if you’re reading. Please. These two features need love! Absolute and wholehearted love!

I’d love to hear everyone else’s experience and suggestions with this second limiting issue I’ve highlighted here.

"\\"" & LEFT(ARRAYJOIN({Methodology Index Codes},"  "),(FIND(",",ARRAYJOIN({Methodology Index Codes},",")))-1) & "\\"," & ARRAYJOIN({Code Order Rollup}, " & ")

Lol. I’ve been writing code-generating formulas for a while. The main issue is that the code cannot be directly used. It must be copied from the formula result to wherever it is going to be used.

I have a scripting automation that I use to automatically sort linked record fields.

I’ll note to make time for researching a scripted method for sorting linked record fields. Am I daft in thinking how useful the ability to sort linked record fields via a sorted table view would be?

And I’m OK with copying out output formula - I’d hate to think of what mischief I’d get up to if we could call them somehow. If anything, they’re saving my eyes when it comes to writing a Switch statement, consisting of many cases and countless field references - what was taking 10 minutes of typo’s per case is now a simple copy and paste. Unfortunately this is where the order of references becomes important, so definitely need to look into your idea of a script to sort orders (and I know straight away I now have two projects that could use this).