Trigger your automations from buttons in Interfaces! With this button type, you can create a net-new automation or trigger a preexisting automation from within Interface designer; you’ll be redirected to the Automations experience to further refine & test the automation before deploying. This button type is great for kicking off repetitive tasks in your team’s workflow, such as:
Use these Interface buttons to navigate internally and externally, including:
Navigate between records: Configure this button to move to the previous and next record of a particular source.
Navigate to URL: Configure this button to open an external URL. Choose from a specific URL field, or a static URL.
Navigate to Page: Navigate to a given page in an interface.
Design tip: We recommend using “Navigate to page” buttons in scenarios when you want to quickly direct your end-users to a single action-oriented page in your Interface (ex: Create a “Report a bug” button that navigates to a bug submission form page). Rather than overloading your Interface pages with navigation buttons for each page, you can use the new Navigation Bar component that showcases all of your pages, launching in October!
3. Copy Record URL: Use this button to quickly copy the Interface link for a given record.
4. Delete Record: Use this button to delete a given record from your base.
In addition to these new button types, we are also launching an exciting enhancement to Update Buttons! Starting today, you can designate an “updated” visual state after the button has been clicked. This makes it easy to see whether a given update has already been performed.
This is just one of many updates we’re making to Interface Designer over the next few months, including: Kanban element, introducing Nav Bars, a redesigned editor, full-page expanded records, form improvements, and Interface Permissions. We can’t wait to see what you build!
This update is available now. If you aren’t seeing these changes reflected, please try clearing your cache.
It would be nice if buttons could use more icons from the pallet of icons Extensions can use (as opposed to just the checkmark), and the same button colors as the Data view buttons.
The button option to open an Interface page is nice. It would be even nicer if a future update allowed us to pass a record ID to the page being opened (so we could for instance open a record’s “parent record” in another interface).
@Kamille_Parks Good catch — that “open record creation form” option in the screenshot is a feature our team is dogfooding at the moment! I’ve updated the screenshot to reflect only the publicly available functionality. No set launch date for that functionality currently, but we’ll likely include it in upcoming Record Creation improvements.
@egordin to your question: I would recommend either creating a navigation button that links to an Interface form page, or turning on the ability for users to add records to Record List & Record Picker elements (see no. 2 in this post if you want more detail).
One of the new actions for Interface buttons is “Copy link to record”.
Note that there is no single “record url”. Each record can have multiple urls that will open the record in different ways.
The “record url” in an automation uses the formula https://airtable.com/baseId/tableId/recordId and will open the record in expanded view in the first view for the table.
The “record url” in the browser when you are viewing a record usually has the format https://airtable.com/baseId/tablId/viewId/recordId and will open the record in expanded view in the specified view. The browser url may also have optional query parameters that say if an extension dashboard is open.
This “copy record link” button in an interface appears to use the format https://airtable.com/baseId/interfacePageId?recordPickerId=recordId
One request that I would have, although it doesnt just apply to buttons, is that it would be great for the buttons to be able to be smaller, similar to how they can be the length of their name in the header. I’d love to be able to have buttons like this but in the actual interface.
This would likely require a bit finer grid in the overall interface, which I too wouldn’t mind.
Thanks for this update, I’ll be using these features extensively.
May I ask for a button that copies record/field contents into the users clipboard? For example, it’s not unusual to have a formula field within a base with a lot of content that’s a little awkward to be visible within an interface - but users are needing to copy the content from
that formula field into their clipboard. An interface button feature to address this would be excellent.
EDIT: My initial Interface Button feedback;
Two other things I’d like to see developed;
Conditional button options. For example, if a field isn’t filled-out, then the button needs to be greyed out/inactive/locked. Scripted logic can obviously prevent a script from executing but the user will still click a button, mindlessly wondering why it no worky - which brings me to my next request;
Have an Interface Element that displays the executed script(s) Status and resulting Execution Log - being mindful that there may be multiple scripts executed, so will need to support scrolling (rather than extending the interface element forever down )
This all sounds great! Excited to implement these in our standing workflows, combined with the new forms this should work well for adding records etc. Can’t wait to see the new nav bar too - any chance of a sneak peek?
Loving the new changes! Can’t wait for the others to come through. One comment on the “Updated” state of the button. It doesn’t allow it to be clicked more than once. If I use this to save an edit, it only allows the button to be clicked once.
I know that Edit doesn’t really need a button, but in some use cases, it helps the user to know that the update has occurred.
Can you please clarify why automations are limited to connection to one button? I have buttons that defer due dates of tasks by 1, 2, and 7 days, and I have those buttons in (2) different task interfaces. Do I really need to duplicate my automations so that each button has a unique automation, even though the automations do the exact same thing?
Yikes, yes - it appears to be hard-coded, one button per one Automation… but I might worry about this problem more if I approach the 50 automation base limit.
It might be worth the thought of having script logic execute of what the one button/automation achieves.
I’d love to see dynamic button labels, so that we can change text/emoji’s depending on table conditions. At the moment, button labels seem to be static. This is a big complaint of mine for Field based buttons too.
I think that limiting each automation to a single button was an important decision in getting this feature out quickly. If multiple buttons could trigger the same automation, there would have to be extra logic in there to make sure that both buttons were referencing the same table. (Or even better, have the triggering table be determined by the triggering record.)
I believe that eventually we will get the ability to trigger the same automation from multiple buttons. It just takes time for Airtable to develop these things, and I am glad the current functionality wasn’t held up until in the meantime.
Remember when we could not re-arrange or duplicate automation actions? Would you have wanted automatons themselves withheld until those features had been implemented? I think not.
Keep in mind if it is very important to you to have multiple buttons trigger the same automation, it is still possible to use an Update button to set the value of a hidden helper field, and have that helper field trigger the automation. The main visual difference is that you will not get the pretty “starting” toast that lets you know the automation has been started.