Yes, this would be great. I recently had to aggreegate two different bases into one. It was a lot of work, but the Pro plan block “CSV Import”, which is outstanding, helped a lot.
Definitely plus 1.
The ability to manage access in a MUCH more granular way (enable editing of records by outsiders, while managing information access), plus better reporting , wld be a game changer…
Easy linking between data is Airtable Core. I use Google Spreadsheets and have a LOT of “bases”. I was considering using airtable, but without this, is unnusable for our company. All areas of a company are linked in real life. Great tool, tought.
I too support this… just adding my 2 cents
The possibility to link to other bases would definitely be a big fat plus !
+1 for this functionality.
Any solution where you require a layered approach to what the user can see (interface) or interact with (data) would really benefit from this (or from having more layered permissions within a single base).
Let’s say I’ve got different business units using the one system. Sales Agents should be able to add in and link certain pieces of information (say leads, phonecalls, sales, etc). But I don’t want them able edit the “Commissions” table (although they need to be able to see it on a dashboard view for example).
Having an “Accounts” Base which was able to interact with the “Sales” Base would be fantastic.
Personal views don’t address this functionality (at least not that I’m aware).
And if we could have multiple bases interacting, it would allow for a better stock interface (not crowding the user with table tabs that are not relevant to them, and confuse their brain).
Adding to the chorus here. Concerned that the first request is 3 years (!!!) ago. This is a fairly basic feature request.
+1. It would be far easier to organize things with this feature.
I offer a few suggestions:
Make it a plus/pro feature. It’s incredibly valuable but not necessary for the free version
Explore which options are easier between:
- Allowing all bases in a workspace to speak to each other (by default), which means any table can be linked to any other table without setting up or changing anything. The transition will affect all current users of Airtable (they may have to fix conflicting information across bases), but once transitioned there will be no more issues.
- Another option is to enable multiple bases to be linked together manually, at which point the user is prompted to change any duplicate table names or potentially conflicting information. These linked bases could be grouped together visually and cycled between when within one of them. They could also share usage limits if that’s an issue (in which case it could be a free feature unable to be abused).
Both options have functional advantages and disadvantages for the users. Nevertheless they are both sufficient to meet the needs of avid Airtable users and open up incredible opportunities down the road.
Another Plus 1 for this feature.
Literally the only thing holding us back - needs to be on the roadmap
It’s embarrassing telling my clients that Airtable doesn’t support this.
This is the only thing keeping me from using Airtable.
+1 for this feature too. Only way to work with our virtual assistant.
+1 - this is really the only way to get a more complete picture of what is happening in any business, as far as I’m concerned the whole point of a database is to be able to automate relationships between, for instance, inventory and order flow. Make it optional, maybe turned off by default if you’re concerned about overwhelming casual users - but please don’t ignore your most requested feature. This is a must for serious integration into our company. Separate departments are useless if they can’t communicate.
+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.
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.
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.