I’m not able to duplicate the problem as you have described it; however, I think you may be describing a related but slightly different behavior.
- In your fourth step, are you linking from the main table – the table where you created the link — or from the linked table?
- If you are linking from the main table, is it the ‘Field on this table that links to the records you want to look up’ that still has the old value, or is it the ‘Tasks table field that you’d like to look up’?
Here’s why I’m asking:
When you create a linked-record field that points to a different table, Airtable creates a reciprocal link, and it gives the reciprocally linked field the same name as the table to which it links. That is, if I create a linked-record field in [Table A] that links to a record in [Table B], Airtable automatically creates a linked-record field in [Table B] that links to [Table A] and is named {Table A}.¹
If I change the name of [Table B] to [Table C] and look at the configuration of the linked-record field that originally pointed to [Table B], it will now show ‘Link to Table C’. However, the name of the linked-record field does not change. You don’t notice this because you’ve undoubtedly given the field some sort of meaningful name in context of your data — for instance, something like {Prospect} or {Next Task} — because otherwise it would have a default Airtable name of {Field ##}, with ‘##’ indicating the sequence number for that field.
If I have or create a lookup field in my main table, the ‘Field on this table that links to the records you want to look up’ value will show the original name of the linked-record field, the value of which now refers to a record in [Table C]. Again, though, this probably goes unremarked, because the name of that field most likely describes the relationship rather than the linked table.
Where this becomes an issue is when following a reciprocal link to a table with a changed name — for instance, if I change the name of [Table A] to [Main Table] and later try to create a lookup field in [Table B] (or, for that matter, [Table C]). While the configuration of my reciprocally linked field will correctly show ‘Link to Main Table’, the field’s *name" will still be {Table A}, so under ‘Field on this table that links to the records you want to look up’ I’ll only have {Table A} as a choice: There won’t be an option for {Main Table}.
Now, I’m not privy to Airtable’s rationale behind their architectural decisions, but I assume it was felt that automatically renaming reciprocally linked fields would cause more harm than good. As far as I know, there is no other situation in which Airtable automatically changes a field’s *name".² In addition, the possibility for confusion occurs only when the reciprocal link retains Airtable’s default name; if you’ve given the reciprocal link a name representative of its logical value, the name of the underlying table is unimportant. (Personally, I try to name both linked and reciprocally linked fields {Link2[Whatever]}, with [Whatever] indicating the meaning of the linked field. For instance, in a ‘ToDo List’ application, my linked field might be called {Link2SubTask} and my reciprocal link {Link2MainTask}. It means I have to remember to rename reciprocal links, which I don’t always manage, but it keeps later name changes from causing difficulties.)
The one place this is all falls down is when dealing with duplicated tables — you’re going to end up with confusing links. Even worse, should you decide v 2.0 of the table is the one you prefer (that is, the modified version of the duplicate), you’ll have to modify every field and formula that references a value in the linked table. And you’ll have to do so before you delete either the original linked table or the original linked-record field; other wise, you’ll be troubleshooting broken fields with no earlier context to guide you. Frankly, though, I’m not certain how this could be handled otherwise, given Airtable is not perfectly omniscient.³
Of course, if your original description was completely accurate, and your base is retaining the original table names, you’ve definitely uncovered a bug, and you should email support@airtable.com with a link to the base in question. (You can find info on how to report issues and share bases with Support here.)
- In Airtable parlance, curly braces — ‘
{’ and ‘}’ — are used to indicate fields; in my posts, I use square brackets — ‘[’ and ‘]’ — to indicate tables.
- Although it does change references to a renamed field, as one would expect.
- Of course, given some of the posts in the Product Suggestions forum, it appears perfect omniscience is a desired feature… .
