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