New Field Type: Button

[David_Krizan]

It would be useful to have a “Button” field type that you could use to trigger an action (e.g., perform a calculation, run a Block, trigger a Zapier Zap, run a script, run small automations, etc.). Even though some of this functionality can currently be hacked-together using other fields like checkboxes in conjunction with Views and Zaps, this is something that has to be explained ad nauseam to new users. So, instead of having a “Submit” checkbox in a workflow that can accidentally ticked, having a distinct “Submit” button would be much, much more clear to novice/infrequent users.

This is a feature currently offered by Coda.

help.coda.io

Overview of Buttons

Learn how buttons can create workflows and an app-like experience in your doc

[BillFrench]

David_Krizan:

perform a calculation, run a Block, trigger a Zapier Zap, run a script, run small automations

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.

[JonathanBowen]

BillFrench:

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.

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

Add "any" functionality to Airtable using Zapier Webhooks Show and tell

I was thinking about how to add some functionality to a base and, for the base user, how they would trigger this. In most web apps functionality will be invoked by the click of a button - save edits, delete a record and so on - but this button functionality isn’t available in Airtable. But…Zapier provides a webhook component that can be invoked to kick off a Zap. I frequently use Zaps in my bases and they are mostly triggered by the standard Airtable triggers - new record or new record in a vie…

[BillFrench]

JonathanBowen:

Zapier provides a webhook component that can be invoked to kick off a Zap.

I’m not sure how many users are annoyed that Zapier - and no one else - are afforded access to Airtable webhooks. Why is that?

Is Zapier simply mimicking webhooks through excessive polling? Or, do they have some insider deal to get notifications of change from Airtable servers?

Webhooks are an essential foundation for integrating anything, and to require that we add additional layers of machinery at additional cost is simply not in the best interest of Airtable or its customers.

[BillFrench]

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

JonathanBowen:

I frequently use Zaps in my bases and they are mostly triggered by the standard Airtable triggers - new record or new record in a vie…

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?

[David_Krizan]

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.

[BillFrench]

David_Krizan:

akin to a Button field type, perhaps it wouldn’t be a traditional data type but instead an “Action”

Just my opinion… I think “action” is the operative term.

If we advocate the idea of non-traditional field types, it will create a level of complexity and confusion that is unfamiliar to most users of information products.

Fields contain data; fields [may] also have attributes such as formatting, color, etc. In stark contrast, rules and actions are a completely separate concept - their influence is applied to fields and their data, but they should be defined in ways that may affect certain records, certain fields, or even entire tables.

Indeed, any sort of integrated scripting model must also be able to impact bases, tables, record collections, a single record, a single field, or - AND THIS IS THE MOST IMPORTANT - a collection of “things” in a field, ergo - proper string-to-array handling. ;-).

[JonathanBowen]

BillFrench:

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

Yeah, I probably wasn’t totally clear on that. I meant the standard triggers for Airtable in Zapier:

JB

[JonathanBowen]

BillFrench:

Zapier to name these “Airtable Webhooks” is misleading

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

[Justin_Barrett]

JonathanBowen:

To my knowledge Airtable webhooks don’t exist, i.e. a URL that Airtable will post to when an Airtable action happens.

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:

[JonathanBowen]

Justin_Barrett:

clicking on a URL in an Airtable field that passes record-specific data to the webhook

Yep - I do similar as described in this post:

Add "any" functionality to Airtable using Zapier Webhooks Show and tell

I was thinking about how to add some functionality to a base and, for the base user, how they would trigger this. In most web apps functionality will be invoked by the click of a button - save edits, delete a record and so on - but this button functionality isn’t available in Airtable. But…Zapier provides a webhook component that can be invoked to kick off a Zap. I frequently use Zaps in my bases and they are mostly triggered by the standard Airtable triggers - new record or new record in a vie…