+1 from us. This would be incredibly useful for us and the lack of it is quite considerably hindering our reporting
Major let down that this is not supported and no news whether or not this feature is coming in the near future.
This feature is the one and only reason that our company is not switching to airtable anytime soon.
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.
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.
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.
@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.