Please forgive the appearance of base and the meaningless table name. I only use this base for random tests.

Are you having problems running the script that I posted?

Perfect - thanks. I am not near a computer today, so I was curious how these links looked.

I made a quick video, how it behaves for me.

Regarding Links, I never made it working. I can type it in, copy and paste it in, update it by integromat/zapier. It’s just not working…

http://somup.com/cYf021itpi

While typing, the only things work are:

Headers, Lists, Blockquotes

It’s just not working as expected.

Quick Update, after futher testing

Finally links are working for me in Integromat / Zapier

Only thing you need to do, put the reference in a new line…

gI'm an inline-style link]l1]

]1]: https://www.google.com

gI'm an inline-style link]l1]

]1]: https://www.google.com

Why airtable doesn’t enables rich text formatting for formulas fields and solves this in a brilliant way

Update (June 25, 2020): The button field is now available for all users — read more in our launch blog post: https://blog.airtable.com/now-available-button-field

Hey all! I’m thrilled to announce that we’re launching the beta for button field, a new field type that allows you to create buttons that trigger customizable actions. Our first action is open URL, which lets you open links based on a URL formula. You can use this to do things like:

• Send emails


• Open Airtable forms with prefilled records


• Create Google Calendar invites


• Open JIRA tickets


• Post tweets


• And much more!

In addition, you can customize the label and style of the buttons.

Holy moly!! THIS IS INCREDIBLE NEWS!!! I’m bouncing off the walls over here!! :grinning_face_with_big_eyes: :thumbs_up:

Y’all I swear Airtable is my fav anything right now. A Button field is a great interpretation of this request, with far more applicability.

I’m really delighted to see how happy this makes everyone, and I agree, it is a useful capability that addresses a void in the Airtable feature set. However, I see a number of issues with this approach not the least of which is the fundamental vernacular, a trajectory that has always troubled me about Airtable.

Raining on the Parade…

Do not read any further if you want to have a long and restful holiday weekend. :winking_face:

Setting aside the new functionality that this makes available, how do you feel about the idea that a “button” is a “field”?

Just saying the term “button field” seems wrong. And to be clear, it’s not worse (or better) than a “formula field”. Isn’t a button an “action” that you attach to a field? Indeed, an action that you should be able to attach to ANY field? Isn’t a formula a functional “attribute” that you should be able to apply to ANY field?

Buttons and formulas are not representatives or proxies for data values, so why are they structurally “fields” in the data tables? The short answer, of course, is that these actions are fundamentally treated like data values and because of this, it rules out the idea that an image might also be a button. Or that string might act as a button.

Unlike other spreadsheet platforms, the data cells in Airtable do not have “depth”; the idea that any given cell may support a variety of attributes such as a button action, or a formula, or both.

Like all of you, when I see new possibilities, such as this new “button field” ooops, I just puked a little in my mouth] I want to be excited but I know what may be coming - more field types that are not really fields.

Shouldn’t EVERY field support button actions?

They’re going to add more actions in the future, which is why “Open URL” is a dropdown. In its initial incarnation it is better than a formula field because there’s styling options included that formula fields don’t have. Also if we’re going to split hairs Airtable is not at all a “spreadsheet platform”. It’s a database. I don’t see why a Date field would need to also somehow be a button.

But, it already is, isn’t it? You click it and it has an “action” - i.e., display a calendar. Ideally, you should be able to display a custom calendar, or integrate the “action” with your own calendar.

I do not at all agree. I don’t want to tiptoe around every field in a database to not accidentally click a link to somewhere or start some process. What other database program works like that, where literally every possible field might also be a “button” of some sort? That sounds like an absolute nightmare UI/UX experience to me.

I’m not suggesting every field be a button; nor am I suggesting that click actions override every (or any) field cell. I’m suggesting that there are use cases and situations where a button action would be useful in the context of field data and in most cases in a contextual menu option.

As it stands, a button field that impacts a specific existing field must be a separate field in Airtable. I believe there are many cases where the action of any given field should not require the addition of yet another field. This is no different than how formulas work in Airtable – for every field that is dependent on a formula, another field must be created. This leads to complex data schemas and confusion. How much simpler would most Airtable apps be if formulas for any field could be joined to the fields they actually impact?

Qckbase, Misoft A*ess (may it rest in peace), rhymes with SmileBaker Pro, … etc. :winking_face:

(post withdrawn by author, will be automatically deleted in 1 hour unless flagged)

FileMaker is a good example of a program that allows you to turn any field — or any other element on your entire screen — into a button. And you can draw your own graphical buttons completely freeform anywhere you want on the screen.

But — here’s the thing — FileMaker gives full 100% design control to the user, which Airtable doesn’t allow. So I think it kind of makes sense for Airtable to have a “button field”. Even though a button is technically NOT a field, it sort of makes sense within the “design constraints” of what we’re allowed to do in Airtable.

You are right, Bill — a button is technically “added functionality”, not an “additional field”. But I think it’s okay within the design constraints of Airtable.

It’s kind of their own unique twist on things, actually. Airtable does get a little “flexible” with their terminology & functionality from time-to-time, but I’m okay with it because they’ve got their own way of doing things that make sense once we get used to it. They’re sort of reinventing things with their own unique spin.

With the new button field, I don’t really see this as a downside. It fits nicely into what we’re already allowed to customize in Airtable. I bet at some point in the future, they’ll give us new “interface layers” & “design layers” that we can work with, but for now, adding buttons into fields seems to work quite nicely.

I’m really super-excited to see how the button field evolves in the future, and I don’t really see any downsides here.

But sometimes, Airtable’s little unique twists DO come with a few downsides. For example, Airtable Support told me that they consider “creating new fields” and “deleting fields” as part of “data entry”, which of course is not technically correct. Creating new fields & deleting fields is part of the structure of a database… that’s not part of the data entry of a database.

So this is why even after you “lock” a view in Airtable, any collaborator can continue adding brand new fields onto your “locked” view. (Similarly, editors can completely delete fields from your entire base — right from a locked view!)

So locked views are not truly “locked”.

To me, this is a downside, because any collaborator can completely modify the “locked” view by creating new fields right on the locked view itself. (And any editor can also remove fields from the “locked” view by deleting fields — directly from the locked view itself.)

But overall, I’m just thrilled to see so many improvements & new features & new functionality in Airtable! Especially all the major improvements in just the last few months! I’m also thrilled that Airtable employees are engaging with us so much here in the community forums.

Overall, I’m just so thrilled about Airtable as a platform for the future. I love the direction that the platform is moving in!

I personally have no problem calling this new feature a “button field”. Right now, we have a “run” button in Scripting block, but its scope is the entire base. I really like the idea of a button a the record level, because then its scope is just that record. So many times someone wants to take an action at the record level. Given the current user interface, I don’t see anywhere else to put a button in the record scope other than in a field.

As for turning other fields into buttons, all fields are interactive at some level, but that doesn’t make them buttons. However I think developers need to tread carefully when overloading fields with too much functionality–it gets too confusing. Even having only two features per field (a stored value and formatting options) things can get confusing. While I would like a lot more robust formatting options, I am leery of adding a actions to existing data fields in the grid view. Save that for other things, like custom blocks.

The most direct comparison to be made with the beta is still Cda’s button columns. FileM is really different from AT, I don’t see that its possible to implement what you’re saying the way they do it, same with Qbase.

In Microsoft Access, a user can create a view in which every single thing (field, background, plain text, images, etc.) can trigger actions. In fact, they could trigger different actions for a click, double-click, right-click, keypresses, etc. This can lead to some very sophisticated user interfaces that resemble full fledged programs. But just because someone can attach actions to multiple events for multiple objects doesn’t mean that they will. It is up to the developer to create a reasonable user interface, just as it is with any other app developer.

I get the examples now, what I was trying to get at was reconciling that functionality with AT’s design without breaking it. Access, FileM, etc. have very different user interfaces in order to accomplish things like that. It just doesn’t seem compatible to me.

@ScottWorld raises a key point …

Indeed, and Airtable can never really truly lock the view from data schema changes because the definition of “fields” is so ambiguous that it includes controls and actions. Locking the schema means locking many of these cherished and necessary features which - as designed - will be difficult if at all possible to separate.

I’m not so concerned that fields of type:action are mixed in with fields of type:data. My concern is the path that this sets the entire future of Airtable on. Imagine how complex the underlying code will become as enterprises insist on schema management features and other mature data management requirements which must also deal with tightly dependent UI bindings.

This is a feature implementation pathway that tightly binds UX with schema and I think it may paint us all into a corner as Airtable matures.

Even the founder of Cda and other Cdans have openly admitted the button field is a risky solution to overcome a key architectural shortfall.

In my old-person (deep legacy) view, fields are all about data, and actions are attributes of fields. A good example - a field of type:selector has a built-in action that is separate and apart from the field’s data. Underneath the action, there is data. It can be filtered, locked, sorted, etc. A button is an action without data which makes me ask - why would it qualify as a field?

To all who have shared great insights concerning my observation, I thank you for pushing back because — at worst — this dialog may inspire some thought about better ways to enhance the already delightful UI/UX of Airtable.

As do I. That part I get and I agree with this observation. The implementation approach is what I think may be problematic.

Let me know what you think of maybe this compromise?

So AT fields already have the Configure Field dialog, and depending on the type of field that dialog has one or two tabs (see Date fields for example). What if there were a third dialog that is basically a recreation Button field’s config options, thus giving any field type the opportunity to tie an action to it.

Now when you focus a field value in AT you get the Expand Record icon as well as the “add” button if its an Attachment or Link field. What if there would also be another button which matches AT’s vision as shown by the Button Field which becomes visible in the left or right corner of the field when the field is focussed (or maybe its visible by default?). Clicking that button runs the action as configured in the field settings. This method would probably have to do away with the button label capability lest we have columns much wider than we’d otherwise desire. If a user wants more flexibility then they’ll use a Button field.

Does that sound like it gets at what @Bill.French and @ScottWorld envision? My brain absolutely only ever works if I can talk out how something looks, not how it behaves so forgive me belaboring a point

You bring up a great point here! I totally agree with you that they could be treading down a slippery slope by mixing data with schema, and by misunderstanding the difference between data and structure.

Especially in light of setting field permissions or future product upgrades.

For the time being, it looks like the screenshot below is how they have solved the field permissions issue for button fields.

Oh, I wasn’t envisioning anything — I am totally fine with how the button field is currently implemented. I was just partaking in the conversation. I don’t think we need buttons attached to other fields, as I rarely use that feature in FileMaker. My buttons are usually standalone buttons in FileMaker, so I like buttons being separate entities.

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 tcollectively] 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 lnudge], 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.

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.