The confusion of linking tables

[ScottWorld]

For newbies to Airtable, one of the biggest confusions when creating a “link to another record” from table #1 to table #2 is that Airtable automatically creates a “reverse link” in table #2 (linking back to table #1). This is actually fantastic & expected & a wonderful help to everyone — except for one thing:

If you have previously hidden any fields inside table #2, Airtable oddly decides to HIDE the new linked record field instead of SHOWING the new field.

This causes so much confusion, because unless you realize that this brand new field has been created & then hidden by Airtable, you might try to create your own “reverse link” in table #2 to point back to the records that you have already linked to in table #1, but of course, it won’t work the way that you would expect it to work — because the field you’re trying to create ALREADY EXISTS but it is just HIDDEN.

To eliminate all confusion, it would be really fantastic if Airtable ALWAYS SHOWED this new field in the 2nd table… unless you have locked a view from changes.

Does anybody else agree with this assessment? And where can I report this as a feature request for Airtable?

Thanks,
Scott

[andywingrave]

Yeah - I agree. It’s just something you get used to after a while. But for sure - It could be more explicit

[kuovonne]

There is a “Product Suggestions” area of the community forum.

While I understand the frustration of not knowing that back links are created when they are hidden, I’m not sure that automatically showing new fields in views with hidden fields is the right approach.

For example, if I’ve hidden some fields in a view that is publicly shared, I don’t want that publicly shared view to automatically show any new fields, not even new back links.

You suggest having locked views to avoid this potential accidental release of information, but locked views are not available with the free plan, and it would be even more confusing if functionality were different between free and paid workspaces.

[WilliamPorter]

Every system has its “gotchas”. Becoming good at the system is, in part, a matter of learning the gotchas.

I’m not sure I agree with your suggestion. Perhaps I don’t understand it. Whether a field is visible or hidden isn’t a property of the TABLE, it’s a property of the VIEW. So, when you suggest that the creation of a relationship, say, from the perspective of the parent table, should automatically make visible the linked field over in the child table, what view in the child table are you thinking of modifying? The first view in the list? What if the user reorders the list?

My own way of dealing with this is to make a grid view for every table that I call ALL FIELDS. It’s always the first view in the list for any table. And all fields and all relationships get defined there. Works for me and finesses this little problem.

William

[ScottWorld]

WilliamPorterTech:

My own way of dealing with this is to make a grid view for every table that I call ALL FIELDS. It’s always the first view in the list for any table. And all fields and all relationships get defined there. Works for me and finesses this little problem.

This is a good idea.