URL--Text to Display Feature

Sorry it isn’t working for you. I don’t have any magic in my script. I’m just following documentation.

let table = base.getTable("Table 10");

let markdownLink1 = `[Link reference][1] also works.

[1]: https://example.com`;

let markdownLink2 = `This is a [plain](https://example.com) link.`
let markdownLink3 = `[I'm an inline-style link](https://www.google.com)`;

await table.createRecordsAsync([
  {fields: {"RichText": markdownLink1}}, 
  {fields: {"RichText": markdownLink2}},
  {fields: {"RichText": markdownLink3}}

In that test, he isn’t using the API directly. He is using Zapier. Now using Zapier does require having an API key, but that is not the same as using the API directly. We don’t know how Zapier is interfacing with Airtable, beyond the fact that it uses the same API key as other APIs. If I recall correctly, there was a thread implying that Airtable might have a special API just for Zapier’s use. Since how Zapier deals with rich text fields isn’t documented, I don’t think it is fair to say that Airtable is not working as documented based on this specific use case.

Cool. Maybe it was broken earlier this year while in beta and now it’s more consistent.

Can you show me a screenshot of Table 10?

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…


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…

[I'm an inline-style link][1]
[1]: https://www.google.com

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

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

:wave: 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!! :smiley::star::+1::tada::star2::dizzy:

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.

1 Like

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. :wink:

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” [oops, 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. :wink:

(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! :slight_smile: 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! :slight_smile:

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.

1 Like

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.