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.
Page 18 / 20
I hope you do not take this the wrong way but 4 years ago you guys said:
it’s certainly something that we are thinking about
if you couldn’t move forward with this feature, as new companies how can we establish confidence with your product, knowing that many of us wouldn’t take this decision easily given that we are migrating from existing environments.
again might be a difficult question but actually wondering how you’d respond to it
Just started using Airtable in the last month and yes +++1 for Linking to other Bases as this would be a game changer for us.
Sure new Beta permissions helps but the ease of linking to another base (particularly if it has a large amount of static data used as reference) would be great.
It looks like this request is 5 years old. Should we just assume it’s not going to be done?
It looks like this request is 5 years old. Should we just assume it’s not going to be done?
Welcome to the community, @Kevin_Cassidy! :grinning_face_with_big_eyes: From my experience, you can trust that Airtable devs are aware of the requests posted here and will add them for internal discussion, but you can also pretty much guarantee that they’re not going to reply in any form, at least not with “Yes we’ll definitely add that” or “No, that’s never going in”, and certainly nothing about timelines for something that might even remotely be in the “Yes” category. However, I have seen features added that were discussed in these suggestion threads.
Long story short: they’re listening. For me, I don’t necessarily see the lack of replies as a bad thing. I’m on another software discussion forum run by the devs of said software, and they’re exactly the same way. The one time they broke that rule and announced that version X was coming in month Y with feature list Z, and that didn’t happen as stated, it wasn’t pretty. Ever since, they reverted back to the silent treatment, and I haven’t heard too many complaints. I’m totally cool with the devs keeping their lips zipped. I know they’re listening, and that’s enough for me.
Welcome to the community, @Kevin_Cassidy! :grinning_face_with_big_eyes: From my experience, you can trust that Airtable devs are aware of the requests posted here and will add them for internal discussion, but you can also pretty much guarantee that they’re not going to reply in any form, at least not with “Yes we’ll definitely add that” or “No, that’s never going in”, and certainly nothing about timelines for something that might even remotely be in the “Yes” category. However, I have seen features added that were discussed in these suggestion threads.
Long story short: they’re listening. For me, I don’t necessarily see the lack of replies as a bad thing. I’m on another software discussion forum run by the devs of said software, and they’re exactly the same way. The one time they broke that rule and announced that version X was coming in month Y with feature list Z, and that didn’t happen as stated, it wasn’t pretty. Ever since, they reverted back to the silent treatment, and I haven’t heard too many complaints. I’m totally cool with the devs keeping their lips zipped. I know they’re listening, and that’s enough for me.
Sorry, I do not feel the same way. There are a couple of items that users have been requesting for 4-5 years that initially received Airtable comment and then fell in a hole. These items do not, on the surface, appear out of bounds for a conventional database program (or even a spreadsheet) and are pretty much standard across a vast number of business cases. In other words, it’s not rocket science.
From a business and personal perspective these limitations constrain me from pushing Airtable past being a standard CRM. Expending resources on the off chance Airtable may come to the party, after 4 years, makes little sense.
Sorry, I do not feel the same way. There are a couple of items that users have been requesting for 4-5 years that initially received Airtable comment and then fell in a hole. These items do not, on the surface, appear out of bounds for a conventional database program (or even a spreadsheet) and are pretty much standard across a vast number of business cases. In other words, it’s not rocket science.
From a business and personal perspective these limitations constrain me from pushing Airtable past being a standard CRM. Expending resources on the off chance Airtable may come to the party, after 4 years, makes little sense.
My guess is that this probably IS a bit closer to “rocket science” within the database world, since they would likely need to re-architecture the entire technical foundation that their entire product was founded on to make this change.
This sort of a massive change touches EVERYTHING in the entire product — from security to sharing bases to workspace management to formula fields to user-friendliness — everything. There’s almost nothing in the product that this sort of change WOULDN’T touch.
Now I’m not saying that it wouldn’t be useful to have in the product — and maybe they’re already working on it — but it’s probably akin to the world’s largest technical challenge for them.
Probably an easier direction for them to go in first would be for them to enable us to “hide tables” within bases, so we could hide tables from certain users that shouldn’t have access to those tables.
It sort of reminds me of the early FileMaker days, which actually had the reverse problem for 19 years:
For 19 years, from 1985 to 2004, FileMaker could only link between 2 external bases, because you could only have one table per base. There was no way to add a 2nd table to a base, because your base WAS the table. One base = one table. So you would end up having solutions with 15 or 20 bases (or more!) just to build a system. When they finally updated the product in 2004 to allow this, it was a massive change to the architecture of the entire product — their entire product had to be rewritten from scratch, and then they had the extra challenge of figuring out a way to migrate old data into the new product. And of course, the file format had to change and everything. So it took them 19 years to figure it out, and they were a massive company owned by Apple!
So, I think that if the Airtable employees feel like this is an important feature, they’re probably working on it. Although I think that there are tons of other massive & more important features that should come first, which are more in the realm of “low-hanging fruit” (in my opinion). And if they would simply give us the ability to “hide tables based on certain criteria”, that could go a long way towards tiding us over on this particular issue of multiple bases.
My apologies as I haven’t yet figured out how to quote text on this forum.
ScottWorld mentioned: “This sort of a massive change touches EVERYTHING in the entire product — from security to sharing bases to workspace management to formula fields to user-friendliness — everything. There’s almost nothing in the product that this sort of change WOULDN’T touch.”
and I feel we are at last coming to the crux of the issue for many of these development requests. Without more definitive guidance from Airtable, I fear that my security concerns will continue.
Never used FileMaker… saw it, didn’t like it, but I did enjoy playing with dBase. Did you know dBase was on the Apollo missions?
Regards
My apologies as I haven’t yet figured out how to quote text on this forum.
ScottWorld mentioned: “This sort of a massive change touches EVERYTHING in the entire product — from security to sharing bases to workspace management to formula fields to user-friendliness — everything. There’s almost nothing in the product that this sort of change WOULDN’T touch.”
and I feel we are at last coming to the crux of the issue for many of these development requests. Without more definitive guidance from Airtable, I fear that my security concerns will continue.
Never used FileMaker… saw it, didn’t like it, but I did enjoy playing with dBase. Did you know dBase was on the Apollo missions?
Regards
I totally agree with ScottWorld. I myself used Filemaker at that time of the great change in the structure of their base. It’s a huge undertaking. Having said that, I think Airtable needs to listen to its users. It’s a demand that is persistent from the community.
This category of application is exploding and if they don’t take this demand seriously, they’re going to lose a lot of players.
I don’t know if this restructuring is part of their Roadmap right now. But if it is, I think it would be a good idea to inform their community. Because the message they’re sending right now is that they don’t care. And I’m sure it’s the opposite, but because they’re not communicating it, that’s the impression they’re leaving.
I really hope they’re going to fix this soon, but for now, this silence translates into a search for alternatives for me.
I totally agree with ScottWorld. I myself used Filemaker at that time of the great change in the structure of their base. It’s a huge undertaking. Having said that, I think Airtable needs to listen to its users. It’s a demand that is persistent from the community.
This category of application is exploding and if they don’t take this demand seriously, they’re going to lose a lot of players.
I don’t know if this restructuring is part of their Roadmap right now. But if it is, I think it would be a good idea to inform their community. Because the message they’re sending right now is that they don’t care. And I’m sure it’s the opposite, but because they’re not communicating it, that’s the impression they’re leaving.
I really hope they’re going to fix this soon, but for now, this silence translates into a search for alternatives for me.
It’s such a shame that this limitation still exists in Airtable after so many years. There are other “citizen developer database” solutions on the market that don’t have this limitation, which is why I build systems on those other platforms instead of Airtable. What Airtable is doing so amazingly well in many other areas (like Blocks, which is so unique and innovative) is completely thwarted by this kind of “fatal flaw.”
I’m using a free trial right now. Trying to understand how this product will work for my business and I have to say, after finding this thread, I need to reconsider how much time I want to sink into Airtable. This limits my idea on how to use the platform tremendously. My service company would blow through 50,000 records on just one base that uses a ton of tables.
My guess is that this probably IS a bit closer to “rocket science” within the database world, since they would likely need to re-architecture the entire technical foundation that their entire product was founded on to make this change.
This sort of a massive change touches EVERYTHING in the entire product — from security to sharing bases to workspace management to formula fields to user-friendliness — everything. There’s almost nothing in the product that this sort of change WOULDN’T touch.
Now I’m not saying that it wouldn’t be useful to have in the product — and maybe they’re already working on it — but it’s probably akin to the world’s largest technical challenge for them.
Probably an easier direction for them to go in first would be for them to enable us to “hide tables” within bases, so we could hide tables from certain users that shouldn’t have access to those tables.
It sort of reminds me of the early FileMaker days, which actually had the reverse problem for 19 years:
For 19 years, from 1985 to 2004, FileMaker could only link between 2 external bases, because you could only have one table per base. There was no way to add a 2nd table to a base, because your base WAS the table. One base = one table. So you would end up having solutions with 15 or 20 bases (or more!) just to build a system. When they finally updated the product in 2004 to allow this, it was a massive change to the architecture of the entire product — their entire product had to be rewritten from scratch, and then they had the extra challenge of figuring out a way to migrate old data into the new product. And of course, the file format had to change and everything. So it took them 19 years to figure it out, and they were a massive company owned by Apple!
So, I think that if the Airtable employees feel like this is an important feature, they’re probably working on it. Although I think that there are tons of other massive & more important features that should come first, which are more in the realm of “low-hanging fruit” (in my opinion). And if they would simply give us the ability to “hide tables based on certain criteria”, that could go a long way towards tiding us over on this particular issue of multiple bases.
As @ScottWorld pointed out, if we could hide tables (tabs), and adjust permissions for each one, that could work. We have a half dozen radically different bases now, because different people on our small team need different things. But they all need some data in common (things like customer or business contacts).
We absolutely need either a way to link from base to base, or customize permissions for a base that would potentially have two dozen tabs/tables.
As @ScottWorld pointed out, if we could hide tables (tabs), and adjust permissions for each one, that could work. We have a half dozen radically different bases now, because different people on our small team need different things. But they all need some data in common (things like customer or business contacts).
We absolutely need either a way to link from base to base, or customize permissions for a base that would potentially have two dozen tabs/tables.
Hiding tables would be amazing! Definitely would be a major step forward in a powerful direction!
This is currently possible with Stacker, which gives an almost-infinite amount of control over which records, fields, and tables your users can view, edit, or create. It even allows you to only show users the records that you want them to see! Yes, they have full record-level permissions!
But linking bases would be the bomb. It is definitely on my list of “Top 10 Killer Features for Airtable”.
This Top 10 list is in my head right now — I don’t actually have this list somewhere for people to reference. :winking_face: Lol.
I LOVE airtable, but not being able to link bases really literally suck.
I’ve been sitting since the day I started using airtable and waited for this function. I’d even sacrifice GANTT and other block features to get this one. It should be the main concern for developing Airtable. Maybe the ONLY, until it’s solved.
We’ve been working on an update for Stacker to allow links between Airtable bases We’d love to test with some of you to make sure we’re hitting your needs.
We’ll start testing this publicly in the next couple of weeks, so sign up here if you’d be interested to check it out first
For my company, this is all about permissions. Stacker looks amazing, but I think Airtable is leaning too heavily on 3rd party support. It makes Airtable even more expensive to use, especially when you add up several 3rd party apps and some charge per record.
Please create granular permissions that provide the following functionality:
Permissions can be granted/removed by: Table, View, Field, and record
Access to VIEW can be granted or removed separately from edit access.
Permission profiles can be customized and collaborators be assigned to a profile giving a range of users the same permissions. Additionally, it would be great to then be able to edit the individuals permissions after assigning the permission profile (essentially using the permission profile as a template).
We are grateful for the efforts to implement permissions, but those recently implemented mostly just protect against someone editing data on accident or maliciously. The functionality of Airtable was not expanded significantly. The added security is nice, but not game changing.
Thanks, this is a really good review. I wanted to get into Fibery, but first wanted a deep dive that tells its strengths and weaknesses in details. This review seems to do just that. Even more surprising that it’s written by the CEO and he’s not sugarcoating any of Fibery’s weaknesses, which gives me more confidence to try it out actually
Clearly, this is a very popular feature request! As Andrew said above, it’s certainly something that we are thinking about, though there are a variety of technical hurdles that would need to be cleared first. Since this is a huge undertaking, we want to make sure that we approach this in the correct way. Any specific ideas on how and why you’d want linked bases to work would be greatly appreciated!
Based on your responses, it seems like there are at least few reasons why one might want to link across bases, all of which raise interesting questions that we need to consider going forward:
Linking across bases could work as a form of granular permissioning (e.g. the Sales team has access to the sales base, and the PR team has access to the PR base, and though they might be able to see selected data from the other team’s base, they wouldn’t necessarily be able to alter it or read all of it). If this is your main reason for wanting cross-base linking: would your needs be met by Airtable implementing more granular permissioning controls at the table level or even the field level (e.g., password protected/hidden/redacted tables/fields that certain users are not allowed to see)? Is it more important to you that different users have access to different bases for privacy reasons (i.e. it’s mission critical that certain users don’t see certain bits of information), or for convenience reasons (i.e. I don’t want all users to see everything in one big base because not all of that data is relevant to their interests)?
Using linking across bases in order to create a manager/“master” base, which draws information from a number of sub-bases. Would your needs be met in this case by some sort of reporting functionality that takes information from many bases, or is it particularly important that this information takes the form of another base?
(Please correct me if I’m wrong about this.) A general sense that a large base with many tables feels cramped—that you have to “cram” what feels like too much data into one place. If this describes you, can you articulate why you feel this way? Is it because of how a base with many tables looks? Is it because of loading times? Is it because you feel like having too much information in one place is overwhelming?
Other considerations: How would you like linking across bases to interact with permissions? Say there are two bases, A and B. A user has access to Base A but not access to Base B, and Base A includes links to Base B. What should the user see when they look at Base A? How would linking across bases work with editing? Should you be able to edit the contents of Base B while in Base A, or should you have to go to Base B first?
There are so many things to say about linking bases, but this is enough for now, I think. :grinning_face_with_smiling_eyes:
For me its actually all points (sorry for being so needy…)
Two bases. Base A and Base B. Base A is the master containing ALL details for ALL employees within the company, base B is a sub-base that I will send out to external companies, such as a travel agent to book hotels for the employees when they are on a certain job, so needs to be editable but not effect the data in Base A(which is a kind of default). So I would need a feature in base B to pull certain fields from base A. ‘Link Fields 1, 2 and 3 from Base A, Table 1 when the value in Base A, Table 1 Field 4 is EXAMPLE JOB’. Base B would then become populated with only the details the travel agent needed, protecting certain private details of the employees.
Within Base A, I would also like to only grant access/views of some fields to certain people. For example, Managers should have access to all data within the base - but Juniors should not be able to see the field regarding individuals salaries, but do need to be able to edit the contact details of every employee.
+1 for linking tables across different bases.
As noted by other people, higher granularity permissions and even aggregation + hiding of tables tab won’t resolve the need.
Collapsing all company’s bases into one means over loaded base which would serve poorly our company users (even if permissions are there it would be extremely hard to manage).
Compartmentalizing using bases is one of AT strength points and we’d better not sacrifice it.
Another approach that might work, depending of your use case, is to sync bases instead of linking them.
I built a tool internally and now it’s in beta, you can have a look here.
In short you can set exactly which records, fields, or view you want to sync with the other bases. And automate it to sync update every minute so it’s always up to date. It sync changes two-way as well.
Also desperately needing to link bases.
Ill use a third party app to get going, but it’s a must for me.
Another approach that might work, depending of your use case, is to sync bases instead of linking them.
I built a tool internally and now it’s in beta, you can have a look here.
In short you can set exactly which records, fields, or view you want to sync with the other bases. And automate it to sync update every minute so it’s always up to date. It sync changes two-way as well.
I was going to build a similar tool out of frustration. Thanks for this. It fills a massive gap and I’ll try your product out.
I think the biggest issue here is the total lack of communication on the #1 most popular forum topic in Airtable’s forum. They could answer definitively that they have no plans to do this, etc. I am not clear why there is a such a lack of transparency on something that clearly people want. It is hard to make decisions related to a product when you don’t know where it’s going.
This topic started in 2015 and is still open ? It is one of the first features I am struggling with. Can anyone give me a few idea where I can invite someone outside my company to have access to a base where I am only sharing one table ? That they can see and edit. I also need to hide fields from them. This is why I thought I could share specific data from one base to another.
It is one of the first features I am struggling with. Can anyone give me a few idea where I can invite someone outside my company to have access to a base where I am only sharing one table ? That they can see and edit. I also need to hide fields from them. This is why I thought I could share specific data from one base to another.
We’d love to test with some of you to make sure we’re hitting your needs.