Editable shared view using Field Button to open URL workaround?

[PedroCerrano]

I have a list of 100-200 sign-up's on a shared view (that's embedded in my website, so it "should" update), and I want to have a public user "Approve" or "Deny" each sign-up by clicking a field button (see screenshot) that would update one Select Field in the respective row. This process happens only once a year.

A simple search on the AT community shows that editable shared views are incredibly popular but not possible. There have even been some creative workarounds (like this from GAP Consulting), but it's too much to ask for someone to open 100-200 forms to update one value for each row. I found this editable shared view workaround, and it got my wheels spinning...

Would it be possible to configure a Field Button to open a URL to a corresponding table (possibly a sync'ed or even two-way sync'ed table) and then use automations to return the appropriate value back?

In my case, clicking on "Approve" or "Deny" would open a URL to send an updated value to the corresponding table that would then update my current table? As I'm typing this, I realize that while the button field: Open URL would enable the button on a shared view, it would also then open a new browser tab... (harumph!)

It's no problem for this "approver" to have a paid Airtable seat, but I would like to severely restrict access for this user down to one view and also preserve the ability to edit. No access to the rest of the views, other tables, or the base is mandatory!

Is there any other way I might accomplish this?

Thanks much! Pedro

[TheTimeSavingCo]

Hm given that you're okay with them having a paid seat, I'd suggest creating an Interface specifically for them and give them access only to that.  They wouldn't have access to the base at all, only to that one interface you created for them

[ScottWorld · Accepted solution]

@PedroCerrano 

You don’t need a paid seat to do this. This can easily be done from either a shared view or a publicly-shared interface.

You would just need to create an approve button and a deny button that open a custom webhook URL from Make.

Then, use Make’s advanced automations for Airtable to run your approval or denial automations.

I give step-by-step instructions on how to do this in this Airtable podcast episode.

My demonstration is done from the context of an Airtable email, but your needs are even simpler since you want to do it from a button in a shared view.

— ScottWorld, Expert Airtable Consultant

[TheTimeSavingCo]

Hmm, if we're opening a new tab to hit a webhook to update Airtable, why not just use Airtable's automation webhooks instead?  That way it'd keep everything in house and we wouldn't have to use a third party tool

https://support.airtable.com/docs/when-webhook-received-trigger

[ScottWorld]

@TheTimeSavingCo 

Because Airtable’s webhooks only support POST requests, not GET requests.

Make’s webhooks support GET requests (in addition to POST requests).

[TheTimeSavingCo]

@ScottWorld  Ahh, you're right, and so just opening a new tab wouldn't work sigh

@PedroCerrano  I threw up a guide on how I'd do this and you can find it here! https://community.airtable.com/t5/show-tell/how-to-guide-update-an-airtable-record-via-a-button-fiel...

[PedroCerrano]

@ScottWorld @TheTimeSavingCo 

Thank you!!!

Never worked with Airtable web hooks, so I'm off to do some research and testing. I'll be sure to go through the podcast and guide! Will report back with an "Accept as Solution"

It is such a delight to have experts like you chime in. I hope that future Airtabler's find this thread to be as helpful them as it is to me.

[PedroCerrano]

Just finished the podcast. Excellent info and highly recommended!

[PedroCerrano]

I marked Scott's response as the solution because he mentioned Make first, but I followed Adam's detailed instructions to pull it off. Thanks, men!