New Field Type: Button

Totally love this idea. The ability to guide users to make stuff happen and give them the ability to understand the difference between setting a state and executing an action is a key requirement in crafting good user experiences.

However… there are trepidation’s with this approach that make me puke a little in my mouth and it stems from the basic idea surrounding the definition of data types.

My concern is that a button is not a data type and defining it as such along with true data types (like numbers, strings, and attachments) seems a bit confusing. Even the Coda folks have recognized this issue and seem to have established a smart way of addressing the differences between data types and functional aspects of cells -

“If you’re thinking about structure in a Coda doc, rows generally represent “things” (like people, tasks, inventory items, etc.) and columns represent “attributes” of those things (like gender, age or address). Having formulas defined at the column level ensures that every row gets the same treatment as the rows above or below it saving you the trouble of remembering to apply formulas as you make changes.”

My second concern is the idea of buttons that perform record-level vs table-level actions. A button “type” cell would obviously perform actions on the localized record. But what if you wanted a button to perform actions on a selection of records, a group of records, a filtered result set, or the entire table?

My third concern is the biggest aspect that’s missing from Airtable at the moment - a way to “run” something, literally anything. This is not currently possible. There is no scripting model or any way to trigger actions (internally or externally), so even if there was a button “type”, we have no way to connect it to anything.

I love this suggestion, but I think Airtable needs an integrated scripting model to make it possible.

Thanks for mentioning Coda - looks like a pretty useful product.

Hi @BillFrench - coincidence, we’ve been thinking on the same thing :winking_face:

Hi @BillFrench - coincidence, we’ve been thinking on the same thing :winking_face:

Totally love this idea. The ability to guide users to make stuff happen and give them the ability to understand the difference between setting a state and executing an action is a key requirement in crafting good user experiences.

However… there are trepidation’s with this approach that make me puke a little in my mouth and it stems from the basic idea surrounding the definition of data types.

My concern is that a button is not a data type and defining it as such along with true data types (like numbers, strings, and attachments) seems a bit confusing. Even the Coda folks have recognized this issue and seem to have established a smart way of addressing the differences between data types and functional aspects of cells -

“If you’re thinking about structure in a Coda doc, rows generally represent “things” (like people, tasks, inventory items, etc.) and columns represent “attributes” of those things (like gender, age or address). Having formulas defined at the column level ensures that every row gets the same treatment as the rows above or below it saving you the trouble of remembering to apply formulas as you make changes.”

My second concern is the idea of buttons that perform record-level vs table-level actions. A button “type” cell would obviously perform actions on the localized record. But what if you wanted a button to perform actions on a selection of records, a group of records, a filtered result set, or the entire table?

My third concern is the biggest aspect that’s missing from Airtable at the moment - a way to “run” something, literally anything. This is not currently possible. There is no scripting model or any way to trigger actions (internally or externally), so even if there was a button “type”, we have no way to connect it to anything.

I love this suggestion, but I think Airtable needs an integrated scripting model to make it possible.

Thanks for mentioning Coda - looks like a pretty useful product.

If there was something akin to a Button field type, perhaps it wouldn’t be a traditional data type but instead an “Action” (or if it needed to have a corresponding data value, it could perhaps have values that represent an action; e.g., Pressed, Unpressed, and maybe akin to In-Process to represent an action that was currently underway but not yet finished).

Theoretically a button/action could also be applied at a table level or even a group level say via an actual button in the column header or even just an ellipsis overflow menu, and clicking such could bring up a dropdown menu with additional options just like existing column headers do.

However, this all would likely require some type of scripting functionality, which is also highly desired.

Scripting functionality/block coupled with built-in Zapier like trigger/actions functions plus Button field types would be an amazing trifecta for building super powerful workflows without having to leave AT. I have to imagine this is where AT is trying to go.

Sorry to come back to this so many weeks later, but I have learned a bunch since I participated in this thread.

When you say “standard Airtable triggers”, exactly what do you mean?

To the best of my understanding, there are no triggers in Airtable; only externally-driven API integrations that sense change and mimic events that perform some sort of external process. In that sense, for Zapier to name these “Airtable Webhooks” is misleading - it’s simply a form of aggressive polling and a little change management voodoo to give us all the impression that they have insider access to something that fundamentally does not exist.

Have I described this accurately? Or, did I miss something big?

Sorry to come back to this so many weeks later, but I have learned a bunch since I participated in this thread.

When you say “standard Airtable triggers”, exactly what do you mean?

To the best of my understanding, there are no triggers in Airtable; only externally-driven API integrations that sense change and mimic events that perform some sort of external process. In that sense, for Zapier to name these “Airtable Webhooks” is misleading - it’s simply a form of aggressive polling and a little change management voodoo to give us all the impression that they have insider access to something that fundamentally does not exist.

Have I described this accurately? Or, did I miss something big?

Again, this is maybe me assuming too much on my naming conventions. The webhook I was referring to isn’t an Airtable webhook but a Zapier webhook component:

So this is just a way to invoke something on Zapier, not Zapier having access to an Airtable webhook that no-one else can access. To my knowledge Airtable webhooks don’t exist, i.e. a URL that Airtable will post to when an Airtable action happens.

JB

Correct.

On the subject of manual triggers, Integromat has a webhook module similar to Zapier’s “Webhooks by Zapier” app. I use that in a few Integromat scenarios as a means of manually kicking off a process, and do so by clicking on a URL in an Airtable field that passes record-specific data to the webhook. It’s what I can do for now in lieu of having a button, so I’m running with it. :slightly_smiling_face:

Again, this is maybe me assuming too much on my naming conventions. The webhook I was referring to isn’t an Airtable webhook but a Zapier webhook component:

So this is just a way to invoke something on Zapier, not Zapier having access to an Airtable webhook that no-one else can access. To my knowledge Airtable webhooks don’t exist, i.e. a URL that Airtable will post to when an Airtable action happens.

JB

Buttons would be great for interacting with Blocks. For instance, we could have a button to “show on map”, which could open up the blocks panel and zoom to that record on a Map Block. Or a “open PDF” button which will pull up its Page Designer page.

At the very least, we should have this kind of functionality and I think record buttons are a good way to implement them.

Sorry to come back to this so many weeks later, but I have learned a bunch since I participated in this thread.

When you say “standard Airtable triggers”, exactly what do you mean?

To the best of my understanding, there are no triggers in Airtable; only externally-driven API integrations that sense change and mimic events that perform some sort of external process. In that sense, for Zapier to name these “Airtable Webhooks” is misleading - it’s simply a form of aggressive polling and a little change management voodoo to give us all the impression that they have insider access to something that fundamentally does not exist.

Have I described this accurately? Or, did I miss something big?

Button fields are in beta now. You can sign up for the beta at this link here:

I have a pro account and I’m signed up for the beta, but the only actions I see available for the button are “Open Page Url”.

Am I missing something? How do I access the other actions like triggering a script?

If you were in the first batch of the beta, they would have sent you an email with a link to reupdate your account with the new actions. If not, you may have to do a hard browser refresh.

Thanks Kamille. I tried a hard browser refresh, but didn’t see any changes… Any other ideas?