URL--Text to Display Feature

I’m a bit late to this fascinating conversation, and at first I was totally on board with the points you’re making, @Bill.French. However, I saw this:

…and then later this:

Aren’t both formulas and buttons in this same vein as Oracle’s stored procedures? A formula outputs data at run-time. Change the data in the fields used by the formula, and the formula outputs new data. The URL tied to a button is driven by a formula, so it’s in the same category as I see it.

I get what you’re saying re: adding the ability to tie actions to other field types, rather than making a field type that appears on the surface to be all action. However, the way I look at it, buttons do contain both data and action. Without the data—the URL created by the button’s formula—the action can’t act.

I’m a bit late to this fascinating conversation, and at first I was totally on board with the points you’re making, @Bill.French. However, I saw this:

…and then later this:

Aren’t both formulas and buttons in this same vein as Oracle’s stored procedures? A formula outputs data at run-time. Change the data in the fields used by the formula, and the formula outputs new data. The URL tied to a button is driven by a formula, so it’s in the same category as I see it.

I get what you’re saying re: adding the ability to tie actions to other field types, rather than making a field type that appears on the surface to be all action. However, the way I look at it, buttons do contain both data and action. Without the data—the URL created by the button’s formula—the action can’t act.

@Bill.French, for me personally, I just don’t see most of the things that you mentioned as a problem. I’m really sorry, but I don’t.

Why? Because these seem like tiny issues that are subjective, whereas I feel like we have MUCH bigger objective fish to fry, such as this GLARING & GIGANTIC security hole in Airtable, which allows ANY COLLABORATOR (including read-only collaborators) to steal 100% of a company’s proprietary data with one click of a button:

I mean, now this is a REAL issue that we have right now, and it’s a major SECURITY issue. If you could chime in on that other thread about that other issue, I would greatly appreciate it!

LOL! I agree 100%. We often get into the weeds about [seemingly] obscure and meaningless debates. Security is a big fat Grouper in fry pan. In that sense, you are clearly a voice of reason - the adult in the room. I promise to spend a few cycles pushing that requirement.

However… like security - certain design choices can impact the ability of a platform to achieve the security required. Just sayin’ … I think you actually caused me to think about security in the context of hybrid field types.

Certainly, mixing data with schema is a really bad idea, but button fields are about mixing actions (and business logic) with schema, not quite as onerous an idea as mixing data and schema. This is akin to stored procedures (in Oracle for example), the difference being that stored procedures are actually data values in fields that are interpreted at run-time. This makes it very easy to treat stored procedures like any other field and like any other data and thus, it doesn’t require complex recognition in the security model or any other aspect of handling schema operations.

And I don’t want anyone to get the sense that we [collectively] have a basis for second-guessing the Airtable team; they’re under a lot of pressure to make it different, make it competitive, and all while not breaking it. :winking_face:

However… this is a topic that is certainly worth considering and being aware of because I’m pretty sure the team is fully aware of the nature of data, structure, and actions. But they may be forced to make some difficult choices and as users, we have to be careful about that which we politely “force” them to do, right?

Recall that for many years, the team has been pressured across many dozens of feature suggestions to add various types of string parsers that were all fundamentally based on the inability to split strings into arrays. I don’t think they caved to all these self-interests and I applaud them for that. I cannot be as kind to them for not implementing Split().

To be a bit more precise about my assertions …

More clarity is needed concerning the vernacular (which is where my commentary began). This is not about “buttons”; it’s about actions. A button is simply (in my view) a poor implementation strategy for field and record-level actions. @kuovonne made this distinction earlier as well.

And yet, we already have many “buttons” (i.e., actions) attached to many of the fields - select lists, dates, links, long text fields, etc. Actions exist everywhere - why not make arbitrary “actions” possible as well?

Can you imagine an action configured for a specific field that would do things like this?

• Right-click, search the web for the value in the field.


• Right-click, search the current table for the value in the field.


• Right-click, search the base for the value in the field.


• Right-click, replace the value in the field with the title-case version of the string.


• Right-click, take the value in the field and pass it to an external web service returning a more complete value for that field.


• Right-click, transform the value of a long text field to summarize the content.


• Click and pass the value of the field to a function or a script block.

This approach would probably achieve all that you’d ever want a “button field” to do without conflating the fundamental aspect of your schema design with hybrid “field” elements.

With this commentary [nudge], I am simply suggesting that Airtable resist adding hybrid field elements and instead follow a consistent and platform-wide approach that expands the opportunity to add new actions and event handlers for all objects starting at the most granular levels (a word in a text field), the field value itself, the record, etc.

LOL! I agree 100%. We often get into the weeds about [seemingly] obscure and meaningless debates. Security is a big fat Grouper in fry pan. In that sense, you are clearly a voice of reason - the adult in the room. I promise to spend a few cycles pushing that requirement.

However… like security - certain design choices can impact the ability of a platform to achieve the security required. Just sayin’ … I think you actually caused me to think about security in the context of hybrid field types.

It’s a good question, but I think the implementation may actually be quite different. Unfortunately, I cannot perform any tests because I have not been given access to the beta.

One test that would be interesting and quite telling about the underlying implementation – can we filter based on the action content of a button? If yes, then your assertion is a good one, and I would be a little calmer about this hybrid field direction. This of course is notwithstanding the idea that – unlike stored procedures - there is an overt UI component coupled with the action “data” and I’m guessing you can’t not have a UI control appear in a button field.

Another test that would useful is to understand how buttons are exposed (if at all) in API results? If they are hidden, they’re not likely data fields.

To be clear - my suggestion that button fields are “akin” to stored procedures was the closest parallel I could think of in a true database environment. They are certainly similar because each approach creates the ability for late binding logic. But given the test I outlined above, that should tell us if your proven hypothesis would have a calming affect on old developers like me. :winking_face:

Ooops! I forgot to address this observation.

Indeed, and I have no beef per-se with formulas except that they are “fields”.

As implemented, each formula can generate field data, but an existing field can’t use a formula. That’s my long-standing complaint about this design and I believe it’s all related to these hybrid fields. If you need a field that is based on a formula, why not make it an attribute of a real field? This exposes the field to the schema, allows you to manage it like any other field within the schema, and provides an opportunity to create very succinct database structures.

A quick test shows that a filter cannot see the action content of a button. However, to me that makes perfect sense. I wouldn’t expect to be given the ability to do anything with the formula output driving the button because that’s not the purpose of the button. Under the current design, the button field isn’t meant to share data outside of itself. The data is only used by the button action. Maybe I just haven’t taken enough time on this, but I can’t think of a situation when I would want to extract the button data (i.e. the URL driving the button action) to use anywhere else. Perhaps later when other button actions are opened up, that feeling might change.

A quick test shows that a filter cannot see the action content of a button. However, to me that makes perfect sense. I wouldn’t expect to be given the ability to do anything with the formula output driving the button because that’s not the purpose of the button. Under the current design, the button field isn’t meant to share data outside of itself. The data is only used by the button action. Maybe I just haven’t taken enough time on this, but I can’t think of a situation when I would want to extract the button data (i.e. the URL driving the button action) to use anywhere else. Perhaps later when other button actions are opened up, that feeling might change.

A quick test shows that a filter cannot see the action content of a button. However, to me that makes perfect sense. I wouldn’t expect to be given the ability to do anything with the formula output driving the button because that’s not the purpose of the button. Under the current design, the button field isn’t meant to share data outside of itself. The data is only used by the button action. Maybe I just haven’t taken enough time on this, but I can’t think of a situation when I would want to extract the button data (i.e. the URL driving the button action) to use anywhere else. Perhaps later when other button actions are opened up, that feeling might change.

Right, I agree with this assessment. Buttons shouldn’t be searchable or filterable, since they’re not data. They’re really just a new interface element that provides clickable actions, which I think is great.

Of course, this leads into @Bill.French’s initial point, which is that buttons aren’t fields, so they shouldn’t be called fields nor be part of the field listing nor even show up as fields in a view.

My guess is that this was the simplest & quickest way for the Airtable engineers to add this flexible new functionality into the product, and it doesn’t seem to be problematic for now.

Although Bill is warning us that “simple & quick” additions often prove to cause problems in the future. This is absolutely true of so many “simple & quick” additions! I don’t personally see this as a problem right now, but time will tell.

I think as @ScottWorld has noted, you’re missing the point of the test. The purpose of this test was to simply understand - is a “button field” an actual field (like a stored procedure), or is it some sort of hybrid like formula fields? Apparently, it is the latter.

Indeed, but you might want access and control over the button input.

If you had an Airtable system with hundreds of buttons - like we often have with databases that contain hundreds of stored procedures - maintaining all of that business logic is far easier if the business logic can be managed like any other data. You can search, replace, document, debug, and a host of other activities if the actionable code is represented as data. The API can access it and treat it as data and the security model can block (or grant) access. This is not the case with Airtable formulas or apparently button fields.

On this dimension alone, I fear (for my clients) that we are creating a complexity of intertwined code and business logic inside hybrid fields that cannot be programmatically inspected, reviewed, searched, or easily debugged – and that seems like a dangerous path. If the integrated configuration of these fields cannot be managed except manually with human clicks and keystrokes, I think Airtable is setting a future of difficult to maintain and modify business and applications rules. The advent of the button field – however needed or well-perceived – seems to deepen an already present dysfunction of the platform.

Even deeper…

We’ve seen in this forum many cases where developers wanted desperately to export formulas for documentation or backup purposes. And many have wanted to automate the creation of complex apps where formula logic could be scripted and built dynamically. Hybrid fields make this almost impossible because they are not really fields. Button fields simply move the platform down that slippery slope a little further and those developers typically flee the platform as soon as they realize the architecture - while perhaps perfect for SMBs - is not so ideal for certain use cases.

I dunno - the more I ponder the implications of burying logic in places that only humans can access while forcing solution designers to expand the number of “fields” in every solution, I see a lot of paint and a very tight corner.

I agree. I think that saying that a button is a field type was probably a design decision based on convenience and ease (both from a design/development point of view, and from a user point of view).

Okay, now it’s finally clicking (no pun inten–…well, okay, maybe partially intended. :winking_face: ) You’re talking about the data stored at the field definition level, not the record level. Is that right? Granted, I’ve not yet used the Airtable API, but I can understand the desire to have access to a field’s definition at that level. However, if I remember some other discussions correctly, this is the issue with all Airtable fields, is it not? The current API can’t access any field-definition-level data for any field type, which makes this a higher-level problem, and not just one tied to this new field type.

Or am I still missing something?

Okay, now it’s finally clicking (no pun inten–…well, okay, maybe partially intended. :winking_face: ) You’re talking about the data stored at the field definition level, not the record level. Is that right? Granted, I’ve not yet used the Airtable API, but I can understand the desire to have access to a field’s definition at that level. However, if I remember some other discussions correctly, this is the issue with all Airtable fields, is it not? The current API can’t access any field-definition-level data for any field type, which makes this a higher-level problem, and not just one tied to this new field type.

Or am I still missing something?

Agree - and it’s likely based on some precedent - the “formula field”, a concept that I pretty much hated from the beginning and the forum shows plenty of evidence I’m not alone.

You may be thinking of only the Standard REST API, which does not have access to any field definition data.

The Scripting API provides quite a bit of metadata, and even read-only access to some field definition data. For example, you can see the colors associated with select fields and the symbol for currency fields. It does not tell you the actual formula in a formula field, but it does tell you if the formula is valid.

The custom blocks beta looks like it offers even more access to metadata. However, I need to finish a few projects before I’ll have the time to take the deep dive into custom blocks.

FileMaker has always had a formula field, and it has been working amazingly well for them for 35+ years. What is the problem you see with formula fields?

FileMaker has always had a formula field, and it has been working amazingly well for them for 35+ years. What is the problem you see with formula fields?

It’s really quite simple - formulas can only live in a field dedicated to the formula. As such, to have any formula logic, you must create another field that really isn’t a field at all. It seems to me that if you need a field based on a formula, create the field and APPLY a formula. That seems logical, intuitive, and embraces all that fields are designed for - storing values - whether computed or otherwise.

This gives you the latitude of creating fields that may conditionally utilize the APPLIED formula, or in some case – bend to API processes or human modifications that can override the formula contingent on the data values, etc.

Presently none of these behaviours is possible with formula fields; they are rigid little clumps of business logic that cannot fathom the idea that something other than their own logic may have something to contribute to that [faux] field’s ultimate value. This is a one-way street that railroads users into creating vastly more fields than typically needed.

If this alternate architecture were supported, it’s a pretty easy leap for a formula in field (a) to update a value in field (b) based on values in (a) or (b) and/or (n…).

There are ways to overcome some of these limitations in Airtable but they require around-the-barn travels and some of the barns are the size of Liechtenstein. You don’t have to search very far in the forum to see some wild workarounds and the vast majority of them seem to stem from formula fields as islands of logic that have no other place to write their results except on top of themselves.

In FileMaker, the formula field is actually called a “calculation field”, and they refer to its logic as the “calculation engine”.

At the beginning — for the first 19 years of FileMaker Pro, this “calculation engine” (“formula engine” in Airtable’s terms) was restricted to ONLY the “calculation field” (“formula field”).

So, for 19 years, we only had one field type (“formula field”) that could perform formulas with the “formula engine”.

But then, they start rolling out the “formula engine” out to many other parts of the product — and it even evolved alongside a “scripting engine” (FileMaker’s version of a scripting language). So now, the “formula engine” and the “scripting engine” power all sorts of amazing things in FileMaker. You can do nearly anything in the product with both the “formula engine” and the “scripting engine”.

But keep in mind that FileMaker is a product with a 35-year history — it came out in 1985. So it took a while to get there.

So I think that in due time, we will see Airtable’s “formula engine” get rolled out to other parts of the product. We’re already seeing this now!

How exciting that we now have a brand new part of the system — the button field — that taps into this “formula engine”!

And soon, we wil probably see this “formula engine” rolled out to other parts of the product as well! And I’m even hoping that they introduce a simple “Airtable scripting language” that doesn’t require learning JavaScript, which is daunting to many.

So, in my opinion, rolling out the formula field to other parts of the system is just the beginning of great new things that are in store for Airtable!

But these things happen slowly over time.

You may be thinking of only the Standard REST API, which does not have access to any field definition data.

The Scripting API provides quite a bit of metadata, and even read-only access to some field definition data. For example, you can see the colors associated with select fields and the symbol for currency fields. It does not tell you the actual formula in a formula field, but it does tell you if the formula is valid.

The custom blocks beta looks like it offers even more access to metadata. However, I need to finish a few projects before I’ll have the time to take the deep dive into custom blocks.

Yep, I recall this vividly. I was at the 2012 FileMaker DevCon in Miami when they finally understood and announced that formulas should not be tightly bound to a special type of field. It took them until 2012 to fully unwind this design choice.

At best, I only have two decades left on this planet; they need to step it up. :winking_face:

Yeah, but no company should feel like they have 35 years to figure out anything and despite it’s long and storied heritage, FileMaker has and continues to struggle. Apple is likely part of the problem. I have a good friend - employee #5 at Claris so the memories, while distant, underscore why it’s good to learn from history.

What would be less daunting?

I don’t think that they are — or ever have been — struggling. FileMaker is perhaps the most powerful cross-platform desktop & mobile database at its price point — with an almost unlimited ability to do nearly anything you want within its programming language. FileMaker’s sales grow every year. And they keep expanding its capabilities every year. And they continue to add tools to make it easy to communicate with other platforms as well. It’s insanely powerful.

Anything easier than writing lines of code from scratch! Airtable knows how to make things easy — they’ll figure it out. FileMaker has a beautifully simple & easy scripting language — yet its power can be unleashed if you want to unleash it.

We’re probably boring these poor forum readers to death by now, so I’ll move this to a message. :winking_face: