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.
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?
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.
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. ;-).
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.
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.
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.
I’d also like other ways to trigger or automate actions in Blocks. For example, I have a personal Expenses base where I log all my receipts. I use the Google Vision Block to OCR scan all receipts periodically in a “No OCR” view (once OCRed via the GV Block, the records disappear from that view).
However, I have to manually trigger the GV Block whenever I want it to run. Granted, I could probably use Zapier webhooks to automate this outside of the GV Block by directly leveraging the GV API, but I’d much rather be able to either A) set the GV Block to automatically run on new records in a given view, or B) run on a set schedule (e.g., daily, weekly). Also, Blocks can’t be accessed or viewed on Mobile, so I have to do view the Web or Desktop app.
Now what I think would be great is if Airtable could create something similar to what Coda offers in their “Packs” functionality. This could be another block (e.g., Scripting block or Workflows block) that basically offers a visual script builder, much like in Zapier or the various other integration services.