@auroraafable
Hum… really ???
-1

@auroraafable
Sorry for the delay… OK, i understand your point of view. I see things positively and appreciate that i can have some space for free so that i can try the product or even recommend the free plan to small non profit organizations.

@Mics_Sky Just trying to be realistic here. It just how it works. Maybe I should have said it in a more positive tone so that it wouldn’t offend you so much? lol

Update
Okay, I edited it. Better? :winking_face:

For us, linking bases would be a matter of workflow and permissions restrictions.

For example, I want the guy in the field to be able to perform an audit or inspection, being able to link the client information, location info, etc, into the inspection fields. But I don’t want him to have access to their contact information, or any other data about them stored in the client table, since I don’t want anything accidentally edited or financials seen.

Secondly, as a matter of easy workflow, it would make more sense for us to do a base for CRM needs… client proposals, their contact information, notes about winning the proposal, how much we are charging them for services, etc. Then I can have my secondary base for the raw data… the equipment we are servicing, where it’s located, technical information, etc… where I can schedule inspections for the equipment included in the client proposals we won. In that way, once a proposal is marked as “won” in the CRM, I can use the same stored data to open a project up in the second base.

This would cut down on the sheer amount of information I’m looking at all at once. Right now I use a different program (just found you guys and I’m loving it so far!) and I have to keep all my tables in the same “book” since there is no way to reference data across books. The amount of data is just confusing to look at. I get lost easily and it’s occurred to me more than once how much easier it would be if I could separate out different aspects of the business/model/flow to accommodate. When I’m working on equipment maintenance proposals, I don’t necessarily need to see every inspection a piece of equipment has ever had, but since it’s all in the same book, I see every detail of everything I have linked. I just need to see the equipment that belongs to the customer on this particular proposal. Even if I hide that detailed part of the view, it still slows down my load time considerably. It would be nice if inspections were housed in another base, so I could reference back to the equipment> it’s owner> our signed agreement without having to cram it all in one.

I still love this software, but this integration would make it unlike anything else on the market in this affordable price range.

Thanks for listening!

@Katherine_Duh Our use case is a bit different from those you’ve described. We are a small team using AirTable mostly to manage marketing tasks related to our products. Each product has a base with tables for projects related to the product. In addition we have a separate base for all marketing materials (videos, brochures, etc). This is separate from the products because many of these materials apply to more than one product. Right now there is no way to tie that back to the products and include those materials in a project.

In addition, every one of our bases currently contains a “Task Owner” table. I would prefer to have one “Task Owner” base, and all other bases could reference that. In addition, as a task owner, I could go to the “Task Owner” base for a compiled list of my tasks from all the bases.

I think both of these scenarios would fall into that “master base” category, but I wanted to provide some additional context on our use case just to clarify the functionality that we need. It just so happens that our products are software products, so I appreciate what it will take to implement this kind of new feature. If you need more detail to develop the user stories for this feature set, feel free to reach out.

Our team absolutely loves AirTable, so keep up the good work!

Definitely #1. I am a landlord who shares information about tenants on a need-to-know basis with vendors. By restricting what they can see more granularly, your product would be much more useful. Now I can share basic contact info and such, which is useful. However, I cannot have a person who needs to edit a table to update a job order or upload pictures and not provide access to the entire base as I understand it. Not useful for any kind of cross-organizational boundary scenario. I was trying to link bases and realized that was impossible. I was glad to see this request for more granular control of the pieces of the base, which would be a very meaningful addition for companies like mine.

Airtable Powers That Be,
Before you solves this problem by enabling base-linking, I’d love to see a solution that’s similar ton"views".

Linking bases sounds powerful, but I worry the product would lose it’s simplicity. The more complex Airtable is the less I can get team members to participate.

Hashim, I wouldn’t worry about that. The way I see it, the ability to link bases would be a very powerful feature, but at the simplest level, linking bases could be similar to linking tables within a base … really more of a lookup function.

Then there are the more complex use cases, like rolling up data from multiple bases to populate a centralized base or the reverse, parsing data from a centralized base to populate other bases. That would be very powerful but much more complicated.

For now, I would be very happy to have the most basic link between bases.

But even if they eventually implement some of the more complex features, that doesn’t mean you have to use them. You could keep your bases as simple as they are today :slightly_smiling_face: while the rest of us drive ourselves crazy linking bases. :confused:

Think of it like an Excel spreadsheet … Most of mine do basic calculations from data all on the same sheet. Sometimes I’ll get a bit more complicated and do calculations from data across sheets in the same workbook. And occasionally, I’ll go completely mad with pivot tables and data from external sources.

But the fact that those complicated options are available doesn’t have any impact on my simple spreadsheets. Those are still simple. And so far, I’ve had the same experience with Airtable. Some of my bases are like that simple Excel workbook with a few sheets that really amount to a collection of lists, while others have lots of tabs, calculations, and links between tabs.

Whatever features they add, you can always choose to keep it simple. :relaxed:

@Keri_Sprinkle I politely and wholeheartedly disagree.

Typically the more flexible and feature rich an application is, the more complicated it is to use it, and the harder it is to get everyone in my org to adopt it (or standardize how everyone uses it)

And adoption is more important than powerful features. Because what good is a custom crm powered by Airbase if the star sales guy won’t enter his data?

Hello there! Airtable employee here. I think you’re both right. Many products tend to become bloated and complex as they gain functionality. That being said, this isn’t strictly necessary–and in fact, our philosophy as a design-driven company centers around conceiving the most elegant possible way to implement enhancements to our product without adding (or at least minimizing) incremental complexity overhead. Our head of product Andrew Ofstad did a talk about this earlier this month: https://www.youtube.com/watch?v=UKotko1nAbU

Then we’ll have to agree to disagree, and I stand by my Excel example. I don’t think anyone would say that Excel is complicated to use. Is the first time user overwhelmed by complex features like pivot tables? Absolutely not, because the advanced features don’t make the basic features any more complicated. In fact, I would guess half of all Excel users don’t even know some of those complicated features exist.

I agree with you on one point - adoption is critical. But if the software is designed properly, and so far Airtable is doing a great job of that, then adding more features doesn’t complicate the user experience and won’t impede adoption. Features should be added based on consumer demand to increase adoption. Right now, in my organization, the inability to link bases is currently preventing us from expanding our use of Airtable, so adding that feature would certainly increase adoption here.

Being able to link bases would be unendingly useful. I work for a major publisher as part of the marketing/publicity. We all work on the same books, but our work is completely separate depending on what team we work on (publicity, online, retail, school & library - and within those teams there are more teams) and is way too complex to all work within the same base as it would results in somewhere around 100 different tables or more within one base - just not workable. It would be great to have one “hub” base where we could store book, author, and other major information like budgets which currently we all have to keep separately. If we had a hub, the department assistant could be responsible for updating all of the hub information, which would update automatically across our individual bases. The hub base would also be able to read information across the rest of them like how much money we’ve spent across all of our teams, etc that is relevant for the higher ups but not relevant for people on the individual teams. Essentially, taking a larger vs more granular view for teams vs departments.

@Keri_Sprinkle i hope you don’t mind a little respectful back and forth on this…

Excel is a perfect example of what I don’t want. The lack of structure hinders collaboration.

What happens is the spreadsheet maker creates her own design of the spreadsheet and ends up “owning” it for life. No one knows why she used cell highlighting instead of adding a new column, or why subtotals are in their own sheet.

This means no one can add data to the spreadsheet or contribute to its design. And the Owner gets stuck accepting data from team members over email, chat, a conversations.

Just thought I’d chime-in, because we’re using Airtable quite heavily now and starting to run into a few limitations that interbase linking would solve.

Our use case goes something like this:

We started using Airtable to manage product pages across multiple websites, tracking which sites each page is live on, where it’s been approved and what sort of content it involves.

The first limitation is that we really want the whole team to be able to see this info and apply filters, without being able to edit data willy-nilly and messing up our beautiful creation. Also: some members, we’d like to be able to edit the “approved” field, without editing any others. Granular sharing permissions would be very useful here.

Right now, we’re sharing private links via Google Sheets so people have access to the views appropriate to themselves and can filter records without affecting everyone else. This is not ideal at all.

Pause for breath. And onwards…

Once we had a powerful database of ‘page content’ set up, we moved onto adding ‘email content’ and linking it to the applicable ‘page content’ record. This works pretty well as is, but again, it’d be lovely to be able to decide who sees content from this table. I’m not sure the sales team really care about it.

Next step was creating a table for all current site issues. We’d assign an issue to a page and keep track of whether the issue was ‘open’ ‘solved’ ‘pending’ etc.

As you can see, we’re moving away from the primary use of the base, and it’d probably be nice to split it into two at this point.

Next step was having a table where Customer Service could log complaints and requests. Then our content team could come along, create an issue and tag the appropriate request. Things are starting to get a bit Inception now, but this means the Customer Service team can easily track the status of their requests. Lovely stuff, but now we’re definitely in multiple base territory.

Lastly, I want to start tagging an issue with the team member who’s working on it, so we don’t start crossing wires. Ideally, we’d have a third base now for company employees.

I hope that, in a rambling kind of way, I’ve highlighted some real-use limitations of Airtable (but also showed just how crazy-useful it is for a company with a ton of data and a big need for collaboration).

My wish list? Interbase linking. Granular permissions. Folders for views.

Love from an Airtable evangelist,

Rob

The benefit to our organization is #3 and its because of needing to manage who has access to what tables in a base. For example, I’d love a master NameAddress table … for employees, clients, patrons, vendors, etc. All names and addresses in one and only one place. But, I can’t keep employee-centric data tables (with salaries, etc.) in the same base that addresses clients and patrons. I need collaboration or visibility/use at the table level. (We’d love to control at the record level. Like giving an employee some data management control over some of their own data records). [But I could vote for #1 depending on how it was implemented. :winking_face: ]

That does work like a champ and can allow for some additional manipulation of the data as it is recorded in the other base.

Still very necessary as a function within Airtable itself though as Zapier can be expensive when you are pushing a lot of data.

Record access control would allow users to see only their records and not records of other users. This is another way of solving the problem that other are seeking to solve with cross-base linking.

For reference, check out how Knack implementer it http://helpdesk.knackhq.com/support/solutions/articles/5000443970-showing-records-connected-to-the-logged-in-user#user-views

Hey Katherine,

• I preface this reply with Praises:
  Both this software and the website are great. I love all the fine detail you all put into your products: the phone app (extremely easy to add a picture, tag items, add multiple tags to a single field, link to other table and see the related content of that table), airtables online (same praises as the phone app), and your website (the commenting interface, change logs, drop down to view replies, pop-up to see the original post, etc)… everything seems to just work and be intuitive (something that is becoming somewhat rare in the android and google world).

• In short, we appreciate you sharing why you have not yet implemented this feature yet. We certainly understand that it is a huge project and appreciate you all informing us of that fact, and we also appreciate you wanting to implement it correctly. Thanks for being a good communicator and sharing your companies concerns before diving into this request.

Now, I want to second the comment of @Polen 's (April 6th, 5:20pm) and @Sarah_Cliff (April 15th, 7:27am): The request to link to other bases is primarily rooted in these desires:

1. Permissions (ie the granting of read or write access of different parts of data to various users)

2. Workflow! (@Sarah_Cliff, thanks for doing a great job expressing these points)

• workflow+permissioning: It is easier to share a whole base with individuals, rather than go thru every table in a base and set permissions.

• workflow+navigation. It feels very cluttered to flip through many tables in one large base (as Katherine_Duh already suggested was a possible reason for the request) .

• Intuitively, I want to click on a base by department and see the related tables (ex, Contracting, Billing, or Customer Relations).

  • this could be achieved possibly by custom views (hiding certain tables upon clicking on that view)

1. Like @Polen stated, perhaps some of the base linking could be gotten around by using a report function.
2. But, like David_Huck stated, the workflow issue, and the desire for multiple bases seems to stem from how you currently have your templates setup: "The current template system encourages a proliferation of bases whereas that " does not seem to be the way in which you are herein encouraging us to use airtables.

Now, I would like to point out that even as things stand now, multiple bases are great! And if you decide to use finer permission management and some sort of report/view to achieve meet objectives behind this feature request, we will be exceedingly happy. Still, as we move forward in this disucssion, I would like us to consider this question: if we can throw all of our tables in one base, what then are multiple bases for?

PS
auroraafable had a great point: multiple bases could allow users to get around the max record requirement. Hopefully you… price the adding of this feature accordingly, and hopefully you wont spend too much resources on something that you wont be reimbursed for, unless you are feeling benevolent :relaxed:

Thanks for the nod!

Also, I thought of this:
If getting around paying is the primary concern with implementing this feature, make this a feature for only paid accounts. Problem solved.

Hey Sarah,

Yeah, I was thinking the same thing: this feature should be a pro-feature, with a 30 day trial.

However, I really do not believe they are terribly concerned with people getting around the record limit (at least that is not their primary concern). Instead, a change/implementation of this caliber is a huge change in programmatic structure if it was not already accounted for, especially if they are considering implementing the same sorts of features between each base that they have between each table.

For our company’s concerns, we would not mind if they did NOT implement all of those fancy features, and instead simply pulled & pushed information between bases. We would be interested in the pro-version if that simple interface were implemented. Still, even with that simple scenario, permission issues will complicate the implementation of this feature.

Yet another +1 for this feature. Would really help clean up the whole structure of my base.

Just wanted to let everyone know that we are reading and discussing your responses. Thanks again, everybody, for the incredibly insightful feedback and for the in-depth discussions of your workflows/use cases. :slightly_smiling_face:

I think Zapier has added multiple steps as a feature recently, this could work?

Multi step zaps are a partial solution and only in some scenarios. In my experience, when we need to sync (which our biggest need) data among bases is when we’re most at risk using Zapier as we end up with a lot of data that’s duplicated and that needs to be updated across a few bases. They recently (if I’m not mistaken) added Find Record and Update Record as actions, allowing for some kind of sync. However, there’s a limit of how many records they can retrieve at a time from Airtable (100 at least for New in View as trigger), so zaps with, say, 15 minutes in between runs may end up with errors if you work with many records.

Re: @Alexander_Sorokin’s comment – He’s got it right, there are ways to play around with Zapier not to get blank records and such, but limitations with New in View trigger (firing only once ever) cause the need of additional redundant zaps (and views) and potential errors (like when a user causes a record to enter a view by mistake, then corrects it–> when the records later enters the view legitimately, it won’t fire the zap) that can render the whole zap idea kinda useless, as manual review and updating has to be done. We just are super careful when we touch fields that are connected with these zaps. I like Zapier but it cannot beat functionality built in Airtable. We love Airtable and we know they’ll find an elegant and effective solution for us… hopefully some time soon.

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.

I believe that for vast majority reasons why people need links to other bases I have a solution which would be the easiest to implement and also very easy to use and very clear from rights point of view. Imagine this scenario:

When I want to link to other base what I will do is following:

I will make ghost of table from the other base into current base.
This ghost table will have exactly the same content as original table in the other base.
This ghost table is read only. So only people with an access to the original table in the other base can make changes (which will automatically propagate into all it’s ghosts).
Once I have ghost table in current base I can link to it.

And the best would be if this ghost table would be based not just on the table in the other base, but also it’s view. So in the ghost table there would be visible only records which belongs to some view.

So for example imagine following scenario:

I have base Sources with tables like Employees, Products etc. In this base I would keep sources for all shared tables.

Than I have base Sales where I need to link to our products from some tables. For that I would make ghost table Products which will be identical to Sources/Products. But in Sales base Products will be read only. And I can link to it from any table in Sales.

If I would need to track who sold what I would need to make ghost table from Sources/Employees and I will call it Sellers. But if in our company we have a lot of people and only handful of them can actually sell something, I would prefer to have just those in Sellers table. So instead of ghosting whole Employees table I would like to make Sellers ghost of Sales team view from Employees table which will show only right people.

I hope that I made my example clear and understandable.