Double Click on Field Name - Restore Customize Field Functionality!

p.s. @Zoe_Bridges, here is another example of how much Airtable has confused new users by hiding field customization upon field creation!

Here are just a few more comments to balance the discussion. :wink:

I have no inside track at all with Airtable but this is clearly not the case. It may seem that it is, but I’m almost certain it’s not and you’re getting these sensations from anecdotal experiences at best.

Airtable could not achieve the level of platform work associated with a specific individual or even a small team. Read this documentation and just imagine the coordinated effort that their entire company had to engage in to make this stuff work. Furthermore, it works well, and it’s highly performant. And, for the most part, there are no disconnects with the product features. This is not easy to achieve.

This is an absolute fact if we can consider the community as a deep representation of customer sentiment. In fact, I searched my ElasticSearch index of the entire community for the past five years and only 6 instances where UI issues concerning field creation popped up and they were unrelated and/or user errors.

If we can use the community data as evidence, the user base seems to have had zero issues with the way it previously worked. I get it - sometimes changes are required in advance of new features, but if that’s at the root of this change, it should be clearly communicated and rolled out in concert with some clear roadmap content explaining why this was necessary (e.g. Apple Lightning Cable - people wanted thinner phones; lightning made this possible).

This is undeniable as well and the data in the community messages prove it. What’s the status of my pet peeve Split()? :slight_smile: Been asking for it for three years. Needed by almost every user for 7 years. It’s a weekend task for a junior-level engineer. [sigh]

@ScottWorld is right again and I rarely agree 80% of the time with him about anything.

Airtable needs a face of technical leadership; one mind, one face, one presence that is fully apprised of all things product management. A liaison who works tirelessly to triage issues and convey them to development while carrying back knowledge from the dev team to the community. There are people in this community who try to help Airtable do this - some are at it 7 days a week without any compensation. Where’s the equivalent Airtable resource that can engage at this level of technical competence while getting a fat paycheck and working as hard as some of your aftermarket developers?

I should have said “each engineering team”. I was told by an Airtable employee that each engineering team has autonomy to work on their own projects, and there is very little communication between teams. I was also told that there is no overall “product manager” overseeing Airtable. Each team has a product manager, but there is nobody overseeing the entire product. The CEO has always acted as the “product manager” up until now, but I suppose that he’s primarily busy trying to raise more VC funds.

All of this would perfectly explain why Airtable is such a dysfunctional product. For example, it would explain why button fields can’t trigger automations, or why Page Designer can’t be automated from anywhere. I mean, there are hundreds of example, but these are just 2 that popped into my head. It would also explain why features get released ONCE and then are left to sit idly & gather dust forever after that. (It might even explain why we unpaid volunteers who are here 7 days per week helping people for free know more about the product than many of their paid support agents do. It seems like each support agent is on their own to learn the product.)

I disagree. For example, Filemaker is a multi-billion dollar company owned by Apple, and their excellent database product is an enterprise-class product that helps run some of the world’s largest companies. Yet their documentation is written by a tiny team of people. I don’t know the exact number, but I’ve heard that it’s less than 5 people handling all of the documentation. In other words, the documentation people at a company are required to engage with all the engineering teams, but that doesn’t mean that teams are engaging with each other.

Lol!! :joy: I agree with everything else you’ve written above!! You totally nailed everything else.

Could not agree more with the comments here! Especially @kuovonne’s ideas around categories.

I’m kind of at a loss for words as to why we are still talking about this nearly a month later.

Because this bad change is still in the product.

1 Like

Haha! Absolutely - I mean…Why is it still in the product :rofl: :sweat_smile: :joy: :joy: :cold_sweat: :disappointed_relieved: :cry: :sob: :sob: :sob: :sob:

1 Like

I hope it is still this way because there is a better solution that is still in development.


I know - I worked with that tiny team in the late 90s; and it was just two people then. (yes, I’m that old)

But I’m not referring to the documentation. I’m referring to the underlying platform - a complexity so vast (as exhibited by the Blocks SDK documentation) that your initial assertion was likely in error. The platform is demonstrably far more complex than a group of freewheeling engineers or a collection of unguided engineering teams could create.

I understand you put a finer point on the “individual developer” nuance. Bottom line - you cannot paint their teams or their underlying accomplishments with a broad brush stroke; they are communicating [with each other] in many ways and the evidence clearly shows this.

As to the other calamities, you are quite right about all your assertions. I’m anxious to learn about what @kuovonne is alluding to.

1 Like

This is brilliant to be able to look at this sort of data, and know that almost NOBODY has ever had a problem with the field customization process. ALMOST ZERO.

Yet, we’ve had hundreds of people — perhaps thousands of people —perhaps MILLIONS of people :wink: — who have had problems with using curly quotation marks in the formula field! And Airtable can’t make their formula engine accept curly quotes?? Or, at the very least, Airtable can’t give users an error message that says “Sorry, the formula engine only accepts straight quotes.”??

This is a great example of the mis-prioritization that is happening with Airtable. So frustrating.


I wasn’t alluding to anything. I was merely honestly stating that I really hope that they are developing something better. Many people complained about the view sidebar testing and there seemed to be little progress until suddenly the current sidebar design appeared, a new design that actually incorporated features suggested by this community.

I think that there is room for improvement in how to create and customize fields, although I won’t attempt to say how it should be prioritized. Anecdotally, I have seen new users intimidated by the array of field types.

I also think that there have been more than 6 instances where field creation and configuration issues have cropped up on this forum. For example, I have seen several issues relating to the fact that formula fields that show numbers default to displaying integers, but actually retain the decimal behind the scenes. Percent field types display as percents by are stored as decimals, which also causes unexpected results when they are used in formula fields. There are numerous issues that crop up related to time zones and local vs. gmt time for date/time fields. People, especially those with database experience, continue to be confused by how linked records work. Issues with lookup fields continue to plague people, and sometimes the solution is to use a rollup field instead. Are url and email fields actually different from single line text fields? I find myself often converting single line text fields to long text fields, not because the data is long but because I prefer the user interface for single line text fields There isn’t a json data type field, but using a long text field works just fine. Should there be a dedicated json field type anyway? There is no location field type, but people have been storing location data and have to decide what field type to use.

Of course, none of these issues relate to the order in which the field name and field type are chosen, which seemed to be the focus of the current testing.

Oh, and to throw out another suggestion @Zoe_Bridges, please think about putting the field description and field-level permissions on the field customization screen, perhaps on different tabs?


It’s difficult to write a query in ElasticSearch that will expose these nuances. My search focused on the key topic of creating fields looking for the keywords that @ScottWorld described in his initial comment.

Thank you @kuovonne for the thoughtful suggestions around improved field ordering, categorization, and description location.

We will continue to consider feedback surfaced in the community forum for this experiment and future product updates. We appreciate everyone’s feedback and continued support of Airtable.


@Zoe_Bridges Thank you for letting us know that Airtable is still monitoring this thread and considering future product updates.

Here is a pie-in-the-sky list of ideas related to setting up and customizing fields.

I would like to see all of the following in a single field customization screen, possibly on different tabs, with consistent names across tabs for all field types. Note that some of these features do not exist yet.

  • the name of the field
  • the field type
  • formatting options
  • the field description
  • a default value for the field
  • possible values (for manually entered fields, e.g. minimum & maximum values)
  • computation settings for computed fields
  • an icon to show in the user interface next to the field name

Formatting options would include anything that affects the display of the value but not how the value is stored internally. Examples of current formatting options include the currency unit in currency fields, the time format in time fields, format of duration fields, and the icon in rating fields. For date/time fields, the option to show local time versus gmt time would should also go under a “formatting” tab to make it more clear to users that choosing local time only affects how the time is displayed, and not how it is stored.

Rules for possible values already exist in a limited sense. Rating fields have a maximum value. You can limit linked record fields to a single value. Number fields can exclude negative numbers. You can limit new linked records to a view. People have been asking for more data validation rules, especially ranges for number fields. People also want to prevent creation of new possible values in single select and multi-select fields.

Many of Airtable’s field types are more about the appearance of a value versus how the value is actually stored. For example, a currency field is basically a number field with a currency symbol. A percent field is a number field with a shifted decimal place and a percent symbol. A duration field is a number field with fancy display options. An email field is basically a single line text field with a different icon in the field column heading. You can reduce the number of field types and shift these appearance issues to formatting options.

(I am treading close to Bill’s idea of having formulas applied to any field type, but I don’t want to go there right now.)

1 Like

Impressive and very thoughtful.

Airtable should employ you as a product requirements manager. Seriously; they should do this right now. Even on a contractual basis - this is precisely the level of consideration and skill to assess the best interests of users that is deparately needed inside their organization.

I disagree; you are being too modest. :wink: This is a list of key requirements to advance the usability while softening the margins between everyday users and the deeper technical aspects of a database tool.


Honestly, @Zoe_Bridges, these changes would be incredible. I never realized how overwhelming all the fields were until @kuovonne’s suggestions. i have absolutely felt confused while trying to understand the purpose of each field type. Why is there an email field type?? I just accepted I was missing something :stuck_out_tongue:

I hope Airtable implements at least the suggestion to condense similar fields into option menus. That would be huge!

1 Like

Totally. I can say with 100% certainty that there is no single individual at Airtable with the skills + the overall product knowledge that @kuovonne has. This is the sort of person that Airtable is sorely lacking right now.

We also have to remember that most of the hires at Airtable have no prior database experience, which makes for a subpar product. People like @kuovonne, @Bill.French, and myself come from DECADES of database experience with high-end database systems.

Thank you for the kind words, but I’m surprised at these comments and I’m curious how you came to these conclusions. There are many very knowledgeable people at Airtable. They just don’t tend to post on these forums very much. As for prior database experience of new hires, I don’t see how you could know statistics on this without being part of Airtable’s HR.


I’m also a psychic! :man_with_turban:‍♂ :stuck_out_tongue_winking_eye:

I’ve had some private conversations with folks at Airtable. My personal takeaway — and this is just my own personal interpretation of what I’ve learned — is that the engineers may indeed have prior experience, but the technical "barrier to entry“ to get hired on the support team or in other non-engineering roles is very low.

But YOU are the hero we need! :star_struck::partying_face: