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 12 / 20
+1 This keeps me from being able to use it for more complex inventory in our company.
Another Plus +1 for this feature.
+1 from us. This would be incredibly useful for us and the lack of it is quite considerably hindering our reporting
This is the #1 feature we want to see implemented in Airbase at our company. At least, perhaps, make it premium or enterprise-level. Clearly, this would give a huge incentive for people to upgrade their plan.
Naturally, you want to separate data belonging to different departments to at least different bases within the same workflow (and ideally between different workflows), so that, for example, your employee registry is in an HR base, but you have a list of teams in a software department’s organization base, and each team can reference employees from the registry as its members. (And ideally, there would be logic to update a team field for an employee in the registry automatically when an employee is added to a team.) Next, in your project tracking base you would create a project and assign it to a team referenced from the organization base.
Right now the only workaround seems to be to cram most of your company’s data in one base. This is not great for a service that offers data organization.
I think the easiest way to implement this is to allow creating read-only copies of tables from other bases. It seems to be an easy feature to build, it would also solve some of people’s problems with managing permissions, and the records in these “linked” tables can count towards the base limit. Just judging from all the comments above, this would be a killer feature.
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:
I appreciate your acknowledging and thinking so carefully about this issue.
I began using Airtable only a few weeks ago. I was immediately impressed with the way Airtable combines relational database structure and logic with ease of use and a simple, attractive UI. My developer coworker might eventually apply your API for data integration with external systems.
My use cases relate to our small non-profit organization built around a Web site for which discrete articles comprise the primary content. The relevant information associated with those articles tends not to change rapidly over time, but it can and will change.
For us, an article list would be one of the tables with potentially mutable data and with the greatest potential to be relevant across multiple Bases. Other such tables include a list of topics to which articles are assigned, and lists of people and entities with whom we interact in some way or otherwise wish to track relationships with.
I’d rather update such general-use information only once, in one virtual “place” – after all, that’s one of the fundamental benefits that a relational database system should offer. However, the cumulative number of standalone tables I envision for my Base ideas – if constrained to a single Base – would be very cumbersome for me to work with and overwhelming for any of my potential coworker clients to be exposed to. In addition, none of those individual clients would benefit from access to more than a fraction of the information that I think would be valuable to our organization as a whole.
I envision a natural, self-evident distribution of this information across multiple Bases, with information on articles, topics, people and entities, et cetera, each available across a substantial subset of those Bases.
Regarding your three points:
At this time, granular permissioning – in terms of access/visibility control – is a negligible interest and concern of ours for our current and prospective Airtable use.
I believe that each of the multiple Bases I envision should be suitable for data entry and online table/form viewing. While I suspect we might ultimately find use for some sort of “master” base functionality, that is speculative and would likely only provide tertiary value.
As suggested above, this IS a major concern. I confess that I’ve yet to make an effort to custom-design forms; I’ve only implemented a single customized Kanban view for one table in my first substantially fleshed-out Base. I may have yet to discover effective ways to hide (or at least mitigate) some of the “clutter” of the nearly 100 tables in that base. That said, the loading time consideration you mention definitely comes into play, particularly when Blocks are displayed in the right sidebar. Also, even for myself as a “designer”, I believe that the visual metaphor of separate Bases with small proportions of shared information will make my work easier conceptually and visually.
As I mentioned, I currently have minimal concern about granular permissions overall when it comes to access/visibility. Regarding “How would linking across bases work with editing?”, I suspect it would be helpful as a designer to choose – on a case-by-case basis – whether or not someone can modify a table shared from “Base B” while within “Base A”. However, if that were a substantive roadblock to implementing inter-Base linking overall, I would gladly sacrifice that ability to hasten access to inter-Base linking.
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:
At our organisation we have a base per Product/Product backlog. Linking bases would allow us to link dependency/integration tasks between products and therefore teams.
+1
Absolutely want to see this feature implemented soon.
+1 - I would take this feature even if there were no other new features for a year.
Love Airtable so far, it has helped extremely with our overall organization.
Also, I apologize, I wrote this out in a new feature request and then found this open ticket so I just copy + pasted my initial quandary.
The one major issue we have started to come across is a way to manage multiple bases the same information in different capacities. i.e. we make clothing, so we would like a way to list all of our assets that go into the making of a final product on one sheet, quantity, date received, vendor, etc. On top of that also have a status sheet that allows us to identify the parts from the other base into the new one with the production aspects, being that the parts of it are now one product in production needing another sheet with status; where is it at, what factory, who is working on it? Beyond that even further another spreadsheet to correlate after this item is now a sellable item in our store and on our e-commerce site. All these aspects are different parts of the whole end product, and yes we could make one massive spreadsheet but it is a lot of information to be all on one base and that is a little too overwhelming and not quite how we would like our inventory/production tracking sheets to work. Is that kind of cross referencing possible?
This feature would unlock so much potential for our team and empower us to spend time more time producing and less time managing.
+1 for me too. I would use it for connecting a central database of people with multiple events that involve the same people. This saves copying and pasting a table between bases, with the potential for duplication errors and version tracking to arise.
PS: if this was a pro feature, I would buy the Pro account just for it.
+1 (+ 100 actually because of all my team)
This is so needed. We now have to have a ton of tables across the same base and many are not relevant from one to another. Would pay more for this.
+1 this would be really useful!
This would be very useful and is quite needed!
+1 We would be able to support multiple levels of user/role access if we had this capability and could extend our use of airtable considerably
+1 We’re trying to find the balance between usability (not having 100s of tables in a base) and power (having different departments all rolling their projects up to company wide efforts and this seems to be the missing link.
+1
It would be great if Airtable could at least give us some indication that this is being explored and a timeframe. It’s honestly the one feature that I think is holding Airtable back from broader uses.
Ps. Otherwise love the product and have been using for quite some time now at work and at home.
@Katherine_Duh @Andrew @Airtable_Team +1 It is highly disconcerting that no one from the company addresses this enormous thread and highly vocal demand. Like most, i’m a paying customer and happy to stay one, but need this functionality.
You’ve touched on a very important point here, which is that it’s incredibly difficult to conceptualize and implement the feature of “linking bases.” When different users have explained to us why they would like to be able to create a link between bases, it’s useful to look at the fundamental problem each person is trying to solve—and it turns out, people’s use cases can be radically different. It’s not clear that in all the cases mentioned in this thread, linking across bases is the best possible solution to that case’s fundamental problem. By this, I mean that linking across bases could be a solution to one person’s particular problem, but it might also create a whole new series of problems. Or it might not! It really depends on the use case.
Dean proposed one possible solution to your problem, which is to have a central/master CRM base. This would make it so that you wouldn’t have to duplicate information about your employees. However, there are still a huge number of potential concerns with how this might overlap with permissions. Suppose you have an outside contractor that needs access to your Company Events base. If they click on a linked record to the Employees base, would they get all the information about that employee, including contact info and other potentially sensitive data? And what if you created a lookup field using the cross-base linked records? This is the sort of situation in which granular and heavily customizable permissions might solve the newly created security problems. But, if we had this granular and heavily customizable permissions system built out, wouldn’t that also eliminate a lot of the need for building cross-base linking in the first place, since many of our users want to use cross-base linking as a form of permissioning?
When thinking about linking bases, we need to take into account every possible implication of the implementation. It’s an extremely complicated problem.
@Katherine_Duh There is a straight-forward common thread in all the use cases. The vast majority of use cases I’m reading here have to do with data normalization and reuse of functionality. People don’t want to duplicate the same data and features across different bases.
It’s pretty simple, IMO:
If I have a list of people, I don’t want to recreate my CRM functionality across multiple bases and have duplication.
If I have a list of products, I don’t want to recreate my entire product-catalog functionality across multiple bases and have duplication.
Most relational databases allow you to link across databases, and some even allow you to link across database servers. This may be restricted to virtual views, read-only access, or whatever. But it is an essential feature when working with complex database, which I’m sure most of your customers evolve into over time.
I haven’t read every post here, but reading several of the recent posts, it seems like an update on your considerations and status on this would be greatly appreciated.
I thought that this idea was so self explanatory that I submitted a support request thinking I was too dumb to find the feature. I second this request.
+1 from here - need this so badly.
Waiting for this feature
@Katherine_Duh - having thought about this for a couple of days, the most elegant solution in my mind would be the ability to “import a view” of a table from one base to another.
If I’m in Base A, I could have a table from Base B represented in A as a read-only, dynamically-updating view. I could then use those records in Base A. Users in Base A would have read-only view access to that table.
Then you could have a feature that shows where else a table is being used, e.g., the Base B team can see that one of their tables has been imported to 3 other Bases, and be in touch with those teams if they’re making a schema change, for instance.
+1 As @Javid_Jamae said, the ability to NOT recreate the same data across different bases (products, for example).
