Introducing Interface Designer 🎉

The fact that Airtable users want external people to have limited edit access to their bases (and no additional access) without paying $240/year per external editor is clear.

I may be making a lot of assumptions here, but Airtable had to decide on a method of building that external user interface first before it could grant limited access to anyone. And the ability to have a custom user interface is beneficial to users who are collaborators already. So it makes sense for Airtable to create that user interface builder and make it available to existing users as soon as the interface builder is ready, even if the other work for sharing the interface outside the organization isn’t ready yet.

Interfaces is still in beta and is barely a week old. It has a a few quirks and doesn’t yet have many of the features we want. However, I’m glad that Airtable decided to make Interfaces available now, rather than waiting until those additional features are built out.

Airtable has shown that they can periodically release incremental feature enhancements. I’m looking forward to seeing those future feature releases.

Sure. But still, it would be nice to just get some insights in their plans. Because a recent interview with Aron doesn’t indicate that they are thinking about making Interface accessible for external user in the near future, as they are aiming for bigger companies with more challenging internal processes as clients.

So please don’t blame some of us for being curious about the future in stead of always be taking by suprise. Is it something they want to do someday, somehow, or is it at the absolute bottom of their backlog? Also useful to give our clients some perspective before they invest (even more) into Airtable.

But all trust in Airtable of course

Absolutely! I completely agree that it is always nice to have more information from Airtable regarding their roadmap.

Any Airtable staff members who have been reading these forums for a while already knows that users (especially consultants) want to know more roadmap information. Airtable just hasn’t chosen to publicly share what they plan to do about this fact.

My post was mostly a reaction to the many posts where people were complaining about Interfaces not being public facing. I wanted to recognize that (1) Interfaces is a great feature, even without public-facing support and (2) I have a lot of hope for public-facing interfaces eventually.

I think that part of the disappointment over interfaces not being public-facing is that Airtable underestimated the desire for public-facing interfaces. People built interfaces assuming that they could be publicly shared, because people really wanted public-facing interfaces. Then they were disappointed that the interfaces could not be public-facing.

If Airtable had announced Interfaces with verbiage that made it clear up-front that interfaces were currently only for base collaborators, there would have been less disappointment. If Airtable had shown interfaces to consultants pre-general availability and discussed setting release expectations regarding what interfaces could and couldn’t do, this mismatch in expectations might have been avoided.

Absolutely! I completely agree that it is always nice to have more information from Airtable regarding their roadmap.

Any Airtable staff members who have been reading these forums for a while already knows that users (especially consultants) want to know more roadmap information. Airtable just hasn’t chosen to publicly share what they plan to do about this fact.

My post was mostly a reaction to the many posts where people were complaining about Interfaces not being public facing. I wanted to recognize that (1) Interfaces is a great feature, even without public-facing support and (2) I have a lot of hope for public-facing interfaces eventually.

I think that part of the disappointment over interfaces not being public-facing is that Airtable underestimated the desire for public-facing interfaces. People built interfaces assuming that they could be publicly shared, because people really wanted public-facing interfaces. Then they were disappointed that the interfaces could not be public-facing.

If Airtable had announced Interfaces with verbiage that made it clear up-front that interfaces were currently only for base collaborators, there would have been less disappointment. If Airtable had shown interfaces to consultants pre-general availability and discussed setting release expectations regarding what interfaces could and couldn’t do, this mismatch in expectations might have been avoided.

A finer point might be to say that Airtable has never recognized the symbiotic relationship between those who produce information and those who consume information. Even where this segmentation is known, many vendors fail to realize that it comes in three sub-flavours:

1. Few producers; many consumers.


2. Many producers; few consumers.


3. Many producers; many consumers.

Each of these flavours creates architectural and pricing complexities the likes of which are rarely considered.

Peeling this back a little further and you have formal users and casual users. A casual user might be a single worker who updates a single record once a week.

In the extreme, imagine a single no-code/low-code developer created a system that produces a unique data set that millions of people could benefit from. Another extreme is a scenario where hundreds of enterprise workers jointly produce information that is ideally suited for one person - the CEO.

Setting aside the inability of Airtable to accommodate mass demand, there is no pricing model that supports either of these success stories discretely. And while these are extreme scenarios, they are intended only to make a point -

Every market of producers has a market of consumers.

If your product addresses the needs of a specific producer but fails to consider the requirements of the producer’s consumers, traction will be fleeting.

Good points.

I see three main overlapping roles:

• System Developers


• Data Producers


• Data Consumers

In general there tends to be fewer developers than producers/consumers. In some business models, developers have to pay more than producers/consumers. (e.g. you pay to develop the system, but the system is free for your users). In other business models developers pay less (e.g. developer for free, pay only when you publish or pay per end user).

If the goal is to democratize software creation, it makes sense to have the same bill rate for developers as producers/consumers. It lowers the bar for someone to become a developer. Thus, while some may grumble that editors have to pay the same as creators for less functionality, I don’t see this as problem because I favor lowering the bar to becoming a developer.

When it comes to data producers, I see four really broad sub-categories:

• regular users who need consistent, full access


• limited users who need only partial and/or intermittent access


• form users who submit data, but do not read any data


• non-human data producers, such as api users

People accept that they must pay for regular users who need consistent, full access. However, people don’t like paying the same amount for limited users who need only partial or intermittent access. It is these limited users that Airtable’s pricing model does not currently address.

The intermittent access issue is sometimes addressed using “floating licenses” or “concurrent licenses”. One challenge with this method is how do you count one Airtable collaborator who is logged in and using multiple instances of Airtable at the same time.

The partial access issue has much tricker technological issues. Airtable’s original architecture was designed to make sharing information easy, and changing it to securely limit read access would probably be very complex. Preventing read access is actually much more difficult than just hiding a table in the user interface. I think Airtable decided that in order to securely “hide” selected data from users, a new interface was needed. (Think about it–all those third party portal systems that provided limited access to Airtable data all have their own user interfaces.) I think that Airtable’s “Interfaces” is a necessary step towards native support for limited read access.

The pricing model change to address these partial-access users also cannot be rolled out until after the method for providing partial access exists. I suspect that Airtable has already been investigating pricing model changes, but has not announced any because there would be no point when the underlying architecture is not ready.

The form users use-case is addressed with Airtable’s forms. These forms are not as robust as people would like, but AIrtable is not in the business of generating complex forms. Of course it would be nice if there were more options for customizing Airtable forms, but where does it end? There are many companies that do provide complex form services.

I also find it interesting that non-human data producers/consumers (REST API usage) do not incur additional fees from Airtable, but other businesses charges additional fees for API access.

Consumers. Airtable is actually really generous when it comes to people who are only consumers of data. Read-only collaborators are free across the board. Sharing filtered views is free. API access to publish using a 3rd party service is free.

Of course, people want even more sharing (e.g. sharing dashboards), but that involves read-only security. As before, I think that interfaces is a step towards read-only security–and there is even a “dashboard” layout.

Great assessment and I like the granularity you added to tease out the developers who I typically lump into the producer category because I’m lazy.

This is a complex topic.

If you charge for API access, you are fundamentally placing a tax on innovation. Most vendors try to avoid disincentives that lead to lower adoption or suppress broader uses. But, even so, Airtable has created an API architecture (unlike other vendors) where a single API “user” could exhibit the load of hundreds of actual users - indeed, a gaggle of really aggressive users. This load - however light or well-designed it may be - is confined to the Airtable account; it is not a common resource with seemingly endless capacity. Unlike almost all other APIs, this API can negatively influence the performance that actual users experience.

Are interfaces only accessible on Desktop?

This is perfect for my use case of sharing job info + daily scheduling with service technicians in the field, but they need to be able to access on mobile or tablet.

I like the implicit metaphor here…

Btw guys, is there a way to connect to multiple filter elements?

You can use 1 filter for multiple “elements” if that’s what you mean?

I wanted to love this (I realize it’s a beta release), and it’s almost what I’m looking for but…

• It seems like in order to use it with others who need even a tiny bit of editing access, you’d have to be on a free plan. Otherwise I’m expected to pay $240/year for someone to interact with a handful of records. Not feasible when working with multiple collaborators. So I can’t have the power and features of Pro and also give people minimal editing access to Airtable records.


• Given that someone has to be a collaborator, they can then access the entire base and all of its tables/views. And since they need editing rights in order to edit in interfaces, they can then do the same in the base itself. Far from ideal.


• As far as I can tell (maybe I’m wrong), collaborators can access all interfaces added to a base, as opposed to just the ones I’d want them to see. So, making myself a personal interface as an admin isn’t possible, since anyone else with access will see all the interfaces. Is this really the case?

It’s a great start but given that tools like Softr allow unlimited applications and up to 10,000 members (with granular access/permissions) for $79/month this doesn’t quite cut it when trying to securely give people a clean view of data (and ONLY that view) with the ability to edit/add a bit of that data.

In a perfect world:

• Let the admin/owner be on a paid plan and not have to also pay for interface collaborators (or at least not full price)


• Access can be granted to just interfaces, and also not to every interface in a base (this can require an Airtable login if need be)


• Collaborators can edit existing records (maybe even place reasonable limits to avoid abuse and people working around upgrading accounts)…maybe they can be assigned to X number of records, and only modify those records.


• (Separate from just interfaces) Don’t make every role cost the same on paid bases, such that a commenter costs the same as someone with total access. Maybe this means that someone on a paid plan would be willing to pay $2 each for 10 commenters. Or $5 each for 20 edit-only-assigned-records collaborators.

I love Airtable and find any excuse to use it, but it’s difficult trying to work with others who need just a small glimpse into data that is relevant to them, and being able to make slight modifications, occasionally. Hopefully the interface designer can be a step in that direction

@Jordan_Scott1 - Interface designer is amazing by itself. Quick question though, can we embed interface designer into html?

@Jyo_D I’m so thrilled to hear that you’re loving Interface Designer! Right now, you are not able to embed interfaces, but this is an awesome suggestion that I’ll make sure to pass along to our product team

Exciting times - what would be truly beautiful for the future is if there was a way to share the interface alone without access to the underlying data and if we could create 1 interface bringing together information from multiple bases - now that would be living the dream