Feature Request: recordActionData.fieldId in useRecordActionData hook

Hi there,

I’m a developer who has been building some custom apps for a company over the last 6 months to help keep Airtable at the center of their operations and integrate various services and APIs right into their Airtable workflow.

One of the most useful features has been using the Button field with an action of opening a custom app. This has allowed the team to trigger various actions right from a record in a view.

Something that would be incredibly useful would be to get the field ID from the record action data that we get from the useRecordActionData hook. This way we could create multiple button fields within one table that perform different actions in one custom app.

At the moment we are limited to one action per table because we cannot differentiate action data from two different buttons on the same table.

Have you tried using the cursor object to get the current field? Airtable Blocks SDK

1 Like

Thanks @Kamille_Parks, this was a really good idea but unfortunately it doesn’t work.

I’ve done some testing and you can use a useWatchable hook to get a “selectedFieldId” with the cursor object. Unfortunately clicking a button in a button field does not select the field. Even if it did there are issues where the selected field could change before the actual app is open and there can be more than one selected field. It was a good thought for a work around but I still feel it would be necessary to get the field ID through the action data of a button click.

Welcome to the Airtable community!

I’ve been thinking about the request, and I don’t think that Airtable will (or should) implement this exactly as written. The field id itself is not the useful information that you want. At best, your app would have to map the field id to what the options the app should use.

Instead, I suggest having the button be able to pass a formula result as query parameters with the record action data. For comparison, a button field that opens a url can take a formula to build the url. Then the app can parse out the query parameters and do whatever it wants with it, much as a webpage does whatever it wants with its query parameters.

A current workaround is to have multiple instances of the app, each configured with slightly different settings. Each button would call the instance of the app with the desired settings.

In any case, best of luck with your custom app development!

1 Like

Thanks for responding @kuovonne . That also sounds like a great idea. Anything that allows us to identify the button would help a lot. Giving the user the ability to pass in dynamic parameters that can be used in the app sounds like it could give the user a lot of flexibility.