Link to other base

[John_Bacino]

So happy that someone finally filled the void left by Dabble DB.

One of the features I found most useful there, but can’t seem to do in Airtable, is linking to entries in another Base. Often, one will have multiple bases which handle distinct aspects of a business or project, but in which one piece of data overlaps.

Example: A political campaign may want Bases for contacting voters, managing events, and recording donations. Those are distinct domains which need their own Bases, but which could benefit from linking parts of them together. For example, it would be great to link donations to the event they occurred at, or voters to donations, or record who attended each event.

In Airtable at present one has to either cram all of those bases into one, or foregoe the linkage which makes this software so great. It may seem like a small thing, but once you can link bases, the sky is really the limit.

[Craig_Mackay]

For us it’s because we already need multiple tables within one base to manage are Product teams, but we have many different Product teams globally working in different cultures and company environments, so we would like to allow them flexibility (Airtables greatest strength similar to Trello), to do their own thing with admin level and be able to summarise it for example group wide status or gantt chart views

[Shawn_Peters]

After several rebuilds I’ve determined a method that reduces tables needed, also eliminating the need for a second base. Requiring only using each record in only one place.

The logic involved requires forgetting almost everything you think you know about database functionality. If anyone is interested I will gladly help.

Airtable should hire me! I’d have a lot of fun evolving it’s uses.

[kbitz]

Any update on this? @Katherine_Duh

[George_Copelan1]

Please!!! And thank you :slightly_smiling_face:

[Shawn_Peters]

George,
I haven’t made a video or tutorial just yet.

Do you have Zoom? We can set up a call ana i can show you what I’m doing. Otherwise I’ll be putting together a video explaining it soon.

Thanks,

Shawn

[typo]

Yes, 1, 2, & 3 are all reasons for wanting cross base linking.

Reason 1: Permissions-- I do film & video production. There are all sorts of layers of permissioning requirements. I don’t want my actors poking around my casting data. I don’t want random crew members to have access to an actor’s private cell number. I don’t need the crew to see us frantically tinkering with the production schedule to make our budget. The easiest way to manage permissioning is by base, but if you can’t link the bases together, you have to custom permission each table for every single member of the production team. That’s time consuming and odds are good that you’re going to miss something and private data will slip through the cracks. (You asked about more granular permissioning. For the reasons stated above, I’m not a fan of solving the problem with more elaborate permissioning options. Bases are a much tidier way to visualize the walls between data than permission options. And individually permissioning rows & columns of 10 different tables for a team of 50 people would be a huge headache.)

Reason 2: Manager/Master lists: One of the primary things I manage and track are people. I need to share individual names/contact info across multiple bases and tables. The name/contact info always stays the same (a master list), but that contact info needs to utilized in many different tables, bases, & workspaces. For every single project, I need to assemble a team from scratch. But I tend to draw from the same batch of people-- If I like someone, I generally want to work with them again. So let’s say I have a crew member named Ella. Ella is great with cameras. She’s the cinematographer on one project in Workspace A, the first Assistant Camera on another project in Workspace B, and the camera operator on a 3rd project in Workspace C. But there’s only one Ella. And in every single production in every single workspace, I need to know her e-mail, her phone number, and remember the fact that she is allergic to peanuts so that we don’t send her into anaphylactic shock on set. (Side note, I’d also need all of the data referenced from the master list-- the lookup data containing phone & e-mail addresses-- to work with AirTable blocks-- one of the reasons I downgraded my subscription is that data from lookup fields didn’t work with the blocks. It’s useless to have a roster of crew members that I can’t e-mail in bulk). Having a master list would also help me track lots of other useful info: across all workspaces, how many of my projects as Ella worked on? Let’s say I’m looking for a cinematographer for my new project, but Ella isn’t available. Who should I ask? If Air Table allowed cross linking of bases (and reporting), I’d be able to apply a filter to my master contact table and pull up a list of everyone who’s ever been in the camera department on any of my productions.

Reason 3: Clutter. If I’m one company, and I do 5 productions per year, and if each of those productions requires at least 10 tables, at the end of 3 years, I have 150 tables (aaaaaaggggh!). Yes, I could consolidate the data on fewer tables by adding project columns to track which data go with which production, but then, instead of being overwhelmed with tables, I’m now overwhelmed with table rows. And, we get back to the permissioning problem because unless I set up filtered data views for every single production, and track the permissioning for each of those views meticulously, the camera department for Production B can see all the info from previous production A. It could cause problems like the cinematographer asking me “You got a $2000 lens on your last production, why can’t I have it on this production?” It could lead to errors like accidentally assigning a camera rental package to the wrong production. Or sending the entire crew to a location address from production A, when they need to be at the location address for production B.

[Shawn_Peters]

There’s a solution to this. It’s about how you’re using the product and it’s capabilities.
Please, someone from Airtable, reach out to me. Let’s have a discussion on how to best illustrate what I’m doing to best serve the community.

Until then, I think I can summarize it like this: Use views to create dynamic access the any base. If you must get info from one base to the next, create a form the includes the needed fields in “Base 2”. Add that form into a field within your workflow of “Base 1”. This can be triggered via Zapier, if needed. I personally have determined there to be a need for only one Base for a person. Everything is capable of being limited by view and used as needed for each individual’s unique set of needs and functionality.
Thanks!

[typo]

Shawn_Peters:

If you must get info from one base to the next, create a form the includes the needed fields in “Base 2”. Add that form into a field within your workflow of “Base 1”. This can be triggered via Zapier, if needed. I personally have determined there to be a need for only one Base for a person. Everything is capable of being limited by view and used as needed for each individual’s unique set of needs and functionality.

Thanks! I’ll try tinkering with it. Let us know if you post a video demo. I’d love to see it!

[typo]

Hmmmm… I was just playing around with this. I can’t quite figure out what you’re doing to make it work. I can use a link to pull up an input form from one base and add it into another, but I still need to duplicate the data. It is true that one can generate a URL link to individual table records, so I suppose there’s some elaborate Zaper/Integromat hack one could put together-- sending links, record by record, from one base into another, then you could use that link to “point” back to the original record. But it still doesn’t solve the problem of cross linking those items within the new base and its tables (or using the data in any way other than looking at it)

[Shawn_Peters]

Yes,
Linking data to sync between bases requires automation.

However, I have a method of using data that allows me to only need one base. (Took awhile to illustrate this to others. Our minds are programmed on how data works. That needs undone)

When I wanted to extend a data record into another base I simplified my definition of what was needed. Shortly later I discovered the solution. Everyone’s solution to this will be unique to their needs.

I offered my work to the Airtable team. They don’t have a need for it.
If anyone would like to have a conversation to help you discover your solution, feel free to email me directly and we’ll setup a time. shawnjp@gmail.com