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.

[Richard_Bramall]

Another Plus 1 for this feature.

Literally the only thing holding us back - needs to be on the roadmap

[Tim_Phillips]

It’s embarrassing telling my clients that Airtable doesn’t support this.

[Amjad_Mohamed]

This is the only thing keeping me from using Airtable.

[EMproperties_UK]

+1 for this feature too. Only way to work with our virtual assistant.

[Blake_McMeekin]

+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.

[Ryan_Wychopen]

+1 This keeps me from being able to use it for more complex inventory in our company.

[Umut_Cankurt]

Another Plus +1 for this feature.

[Alex_Crow]

+1 from us. This would be incredibly useful for us and the lack of it is quite considerably hindering our reporting

[Denis_Semenenko]

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.

[Robert_Segal]

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:

1. 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.

2. 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.

3. 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.