How to determine the "other" side of a linked field

[Matthew_Moran]

While I can do this manually, is there a method either when creating a linked field.. or after, to determine the the field it is linked to.

For instance, we are tracking several fields in a loans file with our contacts table. So, for instance, the fields, Borrower, Co-Borrower, Buyer's Agent, Buyer's Agent TC, Listing Agent, Listing Agent TC, Title Rep, etc. all link to our Contacts. 

I created the relationships from the File_Loans table. So, in the Contacts table they look like this:

I can link a record in each field and determine the linked field - allowing me to provide a better name on this side of the relationship but... Is there a better way?

Thanks.

[Alexey_Gusev]

Hi,
You can choose 'Show dependencies' in field menu. Also, you can add extension 'Base schema' to see linked relations. Example pictures in my first post here, 2 years ago

I'm sorry, but it seems like your design looks very 'unusual' for Airtable. Usually one linked relation between two tables  is maximum.  For the rest data of second table lookups and rollups used, with optional built-in filter function.  Of course, you can create them as many as you want, doing it by purpose, but in my practice, multiple linked relations between 2 tables means 'I created linked relation between these 2 tables and didn't notice they already has one'. 

[Matthew_Moran]

Thank you for your response.

The Show Dependencies indicates my client would need to be on an Enterprise Plan to get access to that information. They are not. I'll look at the Base Schema for future uses. I mapped them by moving a single contact between the ambiguously named Contact fields and saw where it appears in the interface section I've included below.

The schema/data design is fairly customary for a Contact tables used in this way. See below...

We also link from contact back to contact for referrals.

While I could create an intermediary table to hold contact relationships and then define what that relationship is in the intermediary table, Airtable's Interface and View limitations make this a highly undesirable / unworkable solution.

Unworkable from a smooth flow for our client.

We have a File/Loan table. In that table, we have the following fields that are linked to the contact table.

• Borrower
• Co-Borrower
• Listing Agent
• Listing Agent TC (transaction coordinator)
• Buyer's Agent
• Buyer's Agent TC (transaction coordinator)
• Title Contact

This allows us to have a section on their main file/loan form with a simple to populate section of the loan contacts. Borrower and Co-Borrower are found at the top of the form.

The design also allows for some simple, end-of-week, reporting my client sends to the various contact types to give them the status of any loans in process.

Again, if I had greater control over the interface design and could render fields and data via code, I could give my client's an interface with the same simplicity and make different design choices.

I'm still a bit flabbergasted that I cannot create a filtered list on an interface based on data from the record or selected options.

And reporting... whoo boy!! From a reporting standpoint, I've taken to sending most of my Airtable client's data to Google's BigQuery so I can run true SQL queries and create high-performance dashboards.

But... that is beside the point. It would be reasonable for Airtable to let you see the name of, if not name, the opposite side of a linked field as you create it.

[kuovonne · Accepted solution]

> It would be reasonable for Airtable to let you see the name of, if not name, the opposite side of a linked field as you create it.

Yes, this would be nice. If your schema isn't too complex, the Base Schema extension is the easiest way to match a pair of linked record fields. If your schema is really complex, you just get a big hairball of lines.

Another option is to use scripting. Scripting can pull out the inverse link field. But that requires writing a script and is a bit of overkill for a one time thing.

Yet another option is to use my Field List extension. When used with premium license, you can see the options for the fields, including the name of the linked table and the backlink field. Note that this extension only takes a snapshot of the schema at moment you run the extension. The table it creates will not reflect ongoing changes. A premium license is also good in only one base, but it works for the lifetime of that base.

Personally, I developed the habit of always immediately renaming the backlink field whenever I create a new linked record field, and I immediately delete the old backlink field whenever I delete a linked record field.

[Matthew_Moran]

For now, the answer is to name the other side of the link at the time of creation.