Let me again vote for this feature NOT to happen.
My base is slowly swallowing up more parts of the business. It’s replaced three applications we used to use.
Why? Because usage is high. And right now it’s easier to tell someone to use a particular table and view than direct them to a different base and have the records link.
More granular permissions? Yes. Linking bases? No. The complexity will kill the simplicity.
Wanted to mention another option for those looking to “link” Bases.
On your Base 1 include a field on your “index” that is a formula to display the URL of that record.
Base 2 include a field that can store the URL of the “linking” record.
Have two browsers windows and when you need to “link” drag the URL from Base 1 to Base 2 on the “shared” field.
Obviously doesnt give you any search or reporting capability however will allow for easier Cross-Base data access.
I still firmly believe that Hashim_Warren has it right… One Base to rule them all!
I agree, even if this was capable of looking up data from a Spreadsheet that would work in the most part
If the feature were ‘optional’, that would work for both camps. 
I agree, I don’t think the option here is to avoid this new feature, I think it’s to find a great way to implement it and not interfere with those who don’t want to use it. If you don’t have a use for linking between bases - don’t use the feature when it’s live. But definitely listen to the loud feedback of the many who have found countless ways this would help their processes and workflows. My two cents anyways.
Hey @Hashim_Warren,
(please excuse the bold portions; not meant to be disrespectful, but merely add emphasis)
I’m in favor of the one large database. However, my concern is what will be done about INTERorganizational information?
Permissions/views solves the problem of limiting the scope of a base (ie giving other users the ability to view or not view what already exists inside of a particular base). Having one large base with fine tuned permissions / views is beautiful if an organization sees that base as THE central hub where everyone IS going to input data.
Additionally the permission/view solution solves many tangential issues still being raised (see this new post about the desire to collapse/hide lists of tables).
However, what this does not fix is the fact that data which is useful WILL exist and be maintained by other users or organizations… how will that data be most easily/automatically be integrated into THE base?
I love this idea of views/permissions being granular! But, this problem still remains: how will it solve the problem of importing and automatically integrating data from an external source. Thoughts?
The non-profit I work for is using one Airtable base for scholarship applications (with Zapier), and another for keeping track of all the details about our courses. Being able to link the courses to the scholarship applications would be amazingly useful.
Yes please we need this feature.
I also think this would be awesome and would keep my information more organized.
I have read this thread with interest - my background is a ‘database developer’ - always with tools like Access, Filemaker and most recently Access Web Apps.
There’s a lot to like about Airbase but also some issues which this thread encompasses. The suggestion of cross-base links is perfectly sensible and would be useful - but it sounds as though it would be very difficult to achieve. For me the biggest win would be the ability to control access in a better way so that one could deal safely with different use-cases.
My main expertise is HR software, a business I have been in for over 25 years - 15 of which as founder and CEO of an HR software supplier here in the UK which I sold. HR is a great example of how the same database needs secure access for different groups of users:
HR Users - these users generally have access to all data for all staff
Managers - would have access to some of their own data plus their team members
Employees - Only have access to some of their own data
Each user group would need their own User Interface with just the items they have access to showing - and with data secured (to field level) appropriately. The latter can be done by using some read only fields on the forms they have access to - or through the database itself if possible.
There are also processes which are unique to each type of user - for example employees can request leave - to be approved by others. In this example, the Approval field(s) would only be available to approvers.
Translating this to Airtable and this conversation, I think the most suitable approach at this point is to build out a security model which allows the UI to adapt to the user logging in, hiding options that aren’t available etc. Note that generally you would NOT want most users able to change ANYTHING in the design of the app or it’s views - just use it.
Another aspect of HR applications is that they have a LOT of tables - our current HR app in the Microsoft Store has 80 - there are many other examples which would have even more. To make this usable in Airtable there would need to be a way of hiding tables from the table menu bar and only accessing them from view of other tables (or buttons on those views), some other menu option (a table manager perhaps) - possibly only directly accessible by a Creator user type.
Yes, for us we’d love to be able to enter information once, such as a new client- and have it populate across all the databases where the ‘client’ variable is necessary. i.e. We enter a new client on the client master list which then links and populates that field in the accounting table, and project management list etc.
Can you make this the #1 priority for your Roadmap? That’s all you’re missing for most of us. Keep it simple in the beginning where you can only link within bases.
Would happily upgrade and pay for this feature!
In fact, Another way would be to be able to have a different group of tables inside one base. And it would help to have that shown visually by having different colors on the top of the base where you see all tables. Imagine having 2, 3, 3… row of table tabs for each group, one on top of each other. And you could give different permissions for each group. Would that be easier/feasible?
Who proposed allowing “all users to see all data?”
Please please please add the capability to link between bases! I don’t want to risk overloading one base with so many tables; sometimes having more than two levels of categorization (such as the two you can create when you make a base, i.e. Base:Table) on a project warrants creating distinct bases (i.e. Big Project:Aspect 1:[A Distinct Set of Tables]; Big Project:Aspect 2:[A Distinct Set of Tables]).
This capability, along with Airtable’s current trajectory, would make it nigh unstoppable. I want to dump all my data into Airtable, but view things in a narrow enough scope to be manageable.
A sufficient implementation for my needs would be the ability to manipulate the access to the various tables. If I can restrict table access, I can tailor the interface to the user. By building ‘gates’ on sensitive info by using lookup on referenced hidden tables I can control the level of access.
This would be great for me because I currently maintain 2 bases so that inventory cannot see project financial information. If I could hide tables as ‘table sets’ and then give access to the table set, I would have the control similar to linking bases, and I could then join bases that need cross access.
Doable?
Michael
PS This is the biggest advance in the last 5 years for sure. AWESOME job.
25 years ago in an x-Base DBMS we developed applications that handled millions of records in upwards of 70 tables for an aircraft manufacturer; we wrote shop manuals for fleet mechanics. We needed to include data from an engineering database that gets updated overnight 6 days each week. We wrote a custom extract program (with permission from the engineering department’s IT group, of course) of selected data organized into forms we could upload into “fill, use, and empty” tables we thought of as temporary data tanks. Creating and then dumping temporary tables has limitless power and was a standard practice for every programmer and application designer I went to for advice. Our extracts ran every night right after engineering’s tables updated, and every morning when we walked into the office all the external data we needed was at the ready. I suggest this as a sample of a method that solved the problem without introducing data duplication or our-of-synch data entries. I’m thinking that some people who commented might be able to create an output report of selected data from the 2nd database specifically formatted to load a table in their primary database. This bypasses issues with security and with accidentally editing another database’s records, plus it doesn’t require the database engine to manipulate complicated links.
As an afterthought, I’m new to Airtable as of this week (very happy so far), so I don’t yet know its limitations, but in my own experience I never met a database that couldn’t take on one more table!
This is a possible solution that others have hinted at. If there could be a way to allow for a table to be duplicated to another database and that when changes to the source database are made that are also made in batch or on the fly to all the duplicate databases tables that would make a bunch of things possible.
Plus if you could select the fields that you want copied/duplicated that would even be better.
Because then the source table can be protected in the source database. The duplicate table data would be a special read only for all in the new database. This can then be used to lookup information, updated records, link tables without the many problems. If the source is removed or changed in a way that make the link stop the duplicate could remain static but report an error. Changes would not be allowed the other way.
You could do this by batch loading the table over and over but I think that would mess up the links.
If anyone know of way of doing this now please let me know.