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 3 / 20
Another solution that hasn’t been discussed in depth yet on this thread is to improve accessibility. Essentially, many users on this thread are asking to be able to click on one icon and edit some information, and then have that information linked when they click on a different icon and edit a different type of information.
It is so convenient to open a base - there is a customizable icon and also a URL to bookmark. However, users that have a large and sophisticated base may need to access it for 3-4 distinct workstreams. Thus, a user may need to access and navigate the entire base (potentially tedious) for a few routine edits that can be made to a single table. If accessing a single table or a subset of tables/views was as quick and convenient as accessing the entire base, then this issue may be resolved for some users.
In this world of apps, widgets, bookmarks, and shortcuts, users may want the simplicity of entering a URL or clicking an icon to complete a task, project, or workflow (i.e., edit a table or a pre-defined configuration of views and tables within a base, with the rest of the base hidden). This would give users the experience and “look and feel” of opening up a new base, even though they are just seeing a portion a larger base that is hidden and interlinked in the back end.
@Jeremy_Sookhoo you nailed it. Nailed it. If I could set up a collection of views and tables for certain team members and their workflow… even if they have access to other data, that would make me comfortable having lots and lots of tables
Another solution that hasn’t been discussed in depth yet on this thread is to improve accessibility. Essentially, many users on this thread are asking to be able to click on one icon and edit some information, and then have that information linked when they click on a different icon and edit a different type of information.
It is so convenient to open a base - there is a customizable icon and also a URL to bookmark. However, users that have a large and sophisticated base may need to access it for 3-4 distinct workstreams. Thus, a user may need to access and navigate the entire base (potentially tedious) for a few routine edits that can be made to a single table. If accessing a single table or a subset of tables/views was as quick and convenient as accessing the entire base, then this issue may be resolved for some users.
In this world of apps, widgets, bookmarks, and shortcuts, users may want the simplicity of entering a URL or clicking an icon to complete a task, project, or workflow (i.e., edit a table or a pre-defined configuration of views and tables within a base, with the rest of the base hidden). This would give users the experience and “look and feel” of opening up a new base, even though they are just seeing a portion a larger base that is hidden and interlinked in the back end.
To be clear, are you asking for something other than a bookmarkable URL that goes directly to a specific table, view, or record? These already exist–the URL automatically changes to reflect the current view/table/record, not just the Base–and can be bookmarked. Thanks!
I don’t mean to bring a negative vibe to this forum, but I’m curious if you guys at AirTable presently have other feature requests that are as popular or more than this one, and that has also been around for 8+ months now? A cursory look through requests says the answer is “no”, which makes me wonder how seriously you guys take user feedback.
I don’t mean to bring a negative vibe to this forum, but I’m curious if you guys at AirTable presently have other feature requests that are as popular or more than this one, and that has also been around for 8+ months now? A cursory look through requests says the answer is “no”, which makes me wonder how seriously you guys take user feedback.
Hi @Hashim_Warren. I saw that, and I actually took that into consideration when writing. The feature request was created in October 2015, is the most highly requested feature, (I believe) the most highly engaged upon feature, and is “on the roadmap”.
I very much appreciate wanting to implement it carefully and thoughtfully, but taking 8 months to do so with an early-stage product of a well-funded company makes me a bit worried that I’ve trusted my data and operations of my company into a product that takes user feedback and “puts it on the roadmap”… forever. I guess I had higher hopes for faster iterations in line with high-demand user feedback.
Hi Dan, thank you very much for your feedback. A few thoughts:
IMHO, it’s not clear that this is the categorically most-requested and most-important feature. We have a number of other support and engagement channels, including email and chat support, in-person customer conversations, user studies, etc–and there are a number of other, equally-or-more-prevalent feature request patterns we’ve encountered (for instance, Android is a popular one–we’re actively working on it and have a beta right now–as is reporting functionality). It is true that this particular feature has ~50 comments to date on our community forum, but this is still a very small fraction of the total request volume across all channels.
In short, we are actively considering designs and architectures to support inter-Base linking, but this is not a feature which can be trivially implemented, nor one that can be rushed out. I’ll also note that 8 months is not necessarily a long time-frame for major feature development in the world of (especially realtime, cross-device) productivity tools, due to the challenges described above. For instance, it took over a year for a small but very smart team within Google Docs to implement pivot table functionality.
Hi @Hashim_Warren. I saw that, and I actually took that into consideration when writing. The feature request was created in October 2015, is the most highly requested feature, (I believe) the most highly engaged upon feature, and is “on the roadmap”.
I very much appreciate wanting to implement it carefully and thoughtfully, but taking 8 months to do so with an early-stage product of a well-funded company makes me a bit worried that I’ve trusted my data and operations of my company into a product that takes user feedback and “puts it on the roadmap”… forever. I guess I had higher hopes for faster iterations in line with high-demand user feedback.
@Dan_Klos Like you, I think this is a very important feature that will be extremely welcome. I also think their product is viable enough to have a bunch of us using it nonstop and still get more benefits from its existence than drawbacks from its potential-but-still-just-imagined features. That said, I want this to happen so it’d be great to get some updates on its status every once in a while.
@Dan_Klos Like you, I think this is a very important feature that will be extremely welcome. I also think their product is viable enough to have a bunch of us using it nonstop and still get more benefits from its existence than drawbacks from its potential-but-still-just-imagined features. That said, I want this to happen so it’d be great to get some updates on its status every once in a while.
I also think their product is viable enough to have a bunch of us using it nonstop and still get more benefits from its existence than drawbacks from its potential-but-still-just-imagined features.
Very true, @Polen, I agree. As someone in the startup space, in just makes me lose faith when I see high demand for a feature met with vague responses and little apparent concrete action. Thanks for the thoughtful, balanced reply.
Just to throw my two sense in on this… Inter-Base linking for cleaner overall Views is undoubtedly a much needed (and obviously requested) feature however having frequented this community for some time I can certainly say it isn’t the single most requested feature. User / Collaborator permissions I believe would be second only to the Android requests. Inter-Base linking likely comes as a solid third.
Regardless, in my experience at least, Airtable has been “Johnny on the spot” to respond to all my inquiries and help requests going above and beyond to contact me directly by email in many cases. Considering I do not believe I have yet paid a dime (because of credits as I am well past the record limit) I can say without hesitation that I trust in the service and the team of folks steering the product through their “Roadmap”.
I have worked with numerous other platforms to attempt to mimick the ease of data entry (to access methodology) without finding a single other platform that offers a similarly clean input interface, mobile friendly access and ease of import/export functionality.
At this point I look very forward to seeing everything they have to offer in the future however am extremely grateful for the service they offer now.
I’m just going to chime in merely to add my +1 to this feature.
I think the “then people can get around subs” can be easily solved by just making this feature unavailable at the free tier.
Others have already given example and use cases, but I think the core for us comes down to scale. As soon as users are in an medium to large organization, a single base gets very clunky very quickly. It’s less about security and access, and more about organization. Ending up with a base of hundreds of tabs just isn’t feasible. (perhaps this is use case specific, and perhaps Airtable isn’t the solution for us, but I sure was hoping!) :slightly_smiling_face:
I also think their product is viable enough to have a bunch of us using it nonstop and still get more benefits from its existence than drawbacks from its potential-but-still-just-imagined features.
Very true, @Polen, I agree. As someone in the startup space, in just makes me lose faith when I see high demand for a feature met with vague responses and little apparent concrete action. Thanks for the thoughtful, balanced reply.
Not IMHO, but IMOO (in my objective opinion), the Airtable team is extensively and intimately involved with user opinions. It is not fair to criticize the way Airtable is handling this.
The only way for the features you requested to be available more quickly is 1) for Airtable to raise a lot of money to hire full time programmers to be dedicated to this one feature, 2) for people to volunteer to work on it for free (after being trained on their conventions and how the rest of their code works), or 3) for them to release junk that screws up everything great that they have going for them at this time.
Undoubtedly you would not like option 1 as that would mean the free product would become at least $20/month. Option 2 is highly unlikely. You would also probably not like option 3.
I work with a design team team for high end, multi-user, proprietary software, and have an idea of what these guys are going thru. Personally, I am impressed with the product Airtable, its intuitive design, and the teams philosophical and practical understanding of human behavior, product life cycle, business, and program design.
Just to throw my two sense in on this… Inter-Base linking for cleaner overall Views is undoubtedly a much needed (and obviously requested) feature however having frequented this community for some time I can certainly say it isn’t the single most requested feature. User / Collaborator permissions I believe would be second only to the Android requests. Inter-Base linking likely comes as a solid third.
Regardless, in my experience at least, Airtable has been “Johnny on the spot” to respond to all my inquiries and help requests going above and beyond to contact me directly by email in many cases. Considering I do not believe I have yet paid a dime (because of credits as I am well past the record limit) I can say without hesitation that I trust in the service and the team of folks steering the product through their “Roadmap”.
I have worked with numerous other platforms to attempt to mimick the ease of data entry (to access methodology) without finding a single other platform that offers a similarly clean input interface, mobile friendly access and ease of import/export functionality.
At this point I look very forward to seeing everything they have to offer in the future however am extremely grateful for the service they offer now.
As a newcomer to AirTable, I think I’ve been too unrealistic and frankly demanding–as in “I want it now”–for what a reasonable adult (particularly one experienced in tech) should expect. Thanks for your thoughts here.
Hi, I would love this feature as well! I am using one base to track customer CMS interactions, and the other for project management. It would be great if I could see at a glance what interactions have happened per project.
+1 for me
Edit: This would also be good for viewing multiple calendars on one main calendar! That would be great.
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:
Hi Katherine,
I fall into category #2 for a particular feature I’m looking for. I want to have a calendar view for Next Actions or planned meetings and deadlines, and I have many clients. I need to be able to look at only 1 calendar.
Right now I’m using Google calendars. If it’s possible to sync to that instead, that would be good enough, but it would also work just as well to have a master admin base!
I also would like to be able to see a bird’s eye view of all of the projects I’m working on at once.
Thank you!
I agree this would be very useful.
second to this, i would like to be able to connect with apps like sunrise for management purpose.
Yes very useful and necessary in my application.
This would be very helpful, in our case to link between project management and grant tracking/strategy.
Yes please. I would like to have a Base with a table that contains data, that many other Bases and tables coudl pull info from. For me, it would be a master store table, with specifics for many store locations. I would then be able to have many other Bases pull from that master base. It would solve a lot of issues I have with duplicating large bases, and getting timeout/refresh page issues, while Airtable is recreating thousands of rows of data each time I need to create a new table. It would also allow me to have smaller bases, since the largest amount of data would be in the master store base, each of my other bases would only contain 50-100 rows of data. I believe it would put me in the same pay level I am am in, but would have added benefit in ease of operation.
Thank you for making Airtable so great.
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:
An idea on how linked bases would work: my suggested MVP would be to implement base linking through formulas only. At the moment, it’s currently possible to write Amount * Price in a formula, referencing local tables. To reference tables from other bases, we could write:
Inventory.Amount * Sales.Price
Inventory(Amount) * Sales(Price)
Amount(Inventory) * Price(Sales)
Or something like that!
Choice #2 for me. I have different tables for different agents / districts for privacy reasons. I am currently going through the laborious task of moving some agent’s entries to different tables because they have been re-assigned to different districts. Still, I would like to access the data in one place rather than across different tables. #2 would allow me to re-assign agents quickly and still provide the privacy needed and the single table for me.
Thank you for an amazing product!
Just some thoughts on “Link to Other Bases”.
I can’t decide if I am confusing this requirement with a more general one of controlled or restricted access to data.
My example is from CRM.
I want only one table of names (and addresses) for every person with whom our organization has a relationship. Those relationships might be patrons, donors, employees, volunteers, actors, vendors, etc.
Controlling access to employee data for an individual who is an employee is an obvious example. Only certain users/collaborators should have the ability to see/change employee-centric data. In fact, even knowing that the individual is an employee might need to be restricted.
But if the employee is also a patron and/or an actor, those relationships would be known to other collaborator/users – without having to duplicate the core information about the person … their name, address, phone number, etc.
Is this “Link to Other Bases” or a request for more granular access control of tables and/or columns?
Just some thoughts on “Link to Other Bases”.
I can’t decide if I am confusing this requirement with a more general one of controlled or restricted access to data.
My example is from CRM.
I want only one table of names (and addresses) for every person with whom our organization has a relationship. Those relationships might be patrons, donors, employees, volunteers, actors, vendors, etc.
Controlling access to employee data for an individual who is an employee is an obvious example. Only certain users/collaborators should have the ability to see/change employee-centric data. In fact, even knowing that the individual is an employee might need to be restricted.
But if the employee is also a patron and/or an actor, those relationships would be known to other collaborator/users – without having to duplicate the core information about the person … their name, address, phone number, etc.
Is this “Link to Other Bases” or a request for more granular access control of tables and/or columns?
… Or is this just another veiled request for being able to change/delete records from URL-based views?
Just some thoughts on “Link to Other Bases”.
I can’t decide if I am confusing this requirement with a more general one of controlled or restricted access to data.
My example is from CRM.
I want only one table of names (and addresses) for every person with whom our organization has a relationship. Those relationships might be patrons, donors, employees, volunteers, actors, vendors, etc.
Controlling access to employee data for an individual who is an employee is an obvious example. Only certain users/collaborators should have the ability to see/change employee-centric data. In fact, even knowing that the individual is an employee might need to be restricted.
But if the employee is also a patron and/or an actor, those relationships would be known to other collaborator/users – without having to duplicate the core information about the person … their name, address, phone number, etc.
Is this “Link to Other Bases” or a request for more granular access control of tables and/or columns?
Tyler, this is a request to allow you to have a central base for something like the CRM in your example, then maintain a separate base entirely for something like Company Events that you can think link to the CRM base and pull participants from.
The desire is to not have to copy the information to a lot of bases that might benefit from the same ore data, while also not cluttering up one base with a ton of different sheets that don’t need to be there simply for the sake of referencing that first table.
Your thought of restricting access to columns is more a permissions thing but has also been requested and acknowledged by the Airtable team. :slightly_smiling_face:
Tyler, this is a request to allow you to have a central base for something like the CRM in your example, then maintain a separate base entirely for something like Company Events that you can think link to the CRM base and pull participants from.
The desire is to not have to copy the information to a lot of bases that might benefit from the same ore data, while also not cluttering up one base with a ton of different sheets that don’t need to be there simply for the sake of referencing that first table.
Your thought of restricting access to columns is more a permissions thing but has also been requested and acknowledged by the Airtable team. :slightly_smiling_face:
