Scripting for a dummy: remove a single linked record

Hey @Sigurdur_Herman! 

To start, this is a rather straightforward script to implement. I don't mind pumping out a script for you and providing you a walkthrough to look over so you can gain a stronger understanding of what's happening. It's final form depends on the overall context of what would be triggering the automation and I can't do much without those additional details.

I'm happy to go as in-depth or as high-level as you'd like when it comes to a walkthrough of what's happening.

With that out of the way, here are my general thoughts regarding the larger concept of whether someone with no background in development should stay away from scripting.

One of the biggest points of concern from a information security perspective when someone is getting starting with scripting is that it's technically possible for someone to send large amounts of data to other services.

There are many people that would read that and feel justified in doubling down on staying away from scripting. Other people may (and many have) taken that as a warrant to go full anti-Airtable and denounce Airtable as a terrible platform that is completely insecure and unsafe.

I can't help but laugh a bit when I see these reactions. There are two reasons why.

The first is that I think that the average user with contributor, creator, or owner permissions is able to do many things that would put poorly written, suboptimal script to shame. 

Want an example? Look no further than these two buttons:

These buttons can prove to be remarkably devastating in the hands of everyday users.

Here's the second reason. If someone doesn't know how to write JS and just starts trying to do random things with an Airtable script, it's going to take an impressive amount of effort for them to put something together that actually manages to do something destructive.

If someone with no programming experience managed to put together an API request to even get somewhat close to sending requests and data to external services without someone noticing, I would be incredibly impressed.

Sure, you have a ton of places online where you can learn how to write JS, but it doesn't take long to hop into Airtable and realize that many parts of vanilla JS don't work the way they would in another environment. There's barely any documentation on which web APIs are supported within Airtable scripts. Despite many web APIs being present in the scripting environment, many of them don't behave or work in any understandable capacity.

It's easy to read this and interpret that I'm trying to dissuade any interested person from learning how to write Airtable scripts or use it as a stepping stone to exploring the wider landscape of programming. That's not true at all. In fact, I think that if someone is already using Airtable and wants to learn to write code, it would be easier in a lot of ways to learn the basics with Airtable scripting because it provides a wider context for what you're actually doing that a lot of new programmers don't have when they're first getting started.
You can actually look at a record, piece of data, or a table and understand visually what your script is doing and how you're using JS to do that.

My goal here is to communicate that scripting is just as dangerous as never using a script in all of the time you use Airtable, they're just dangerous in different ways.

Okay. I'll stop my brain dump there.
I know that this wasn't really within the scope of your original question, but these thoughts are mostly written in the context of people who might be reading through this thread sometime in the future.

Well, I'll be damned. That is some delightfully lateral thinking; I love it. Thanks, @Alexey_Gusev!

Thanks for sharing your thoughts, @Ben_Young1! It's good to know that I'll be basically unable to break anything, even if I were to try xD

Alexey's solution will work without scripting, I think, so I won't need to delve into the jungle of scripting - yet. I'm sure I'll run into some impossible-without-scripting task soon enough, though!

Thank you so much for this solution, @Alexey_Gusev!!! I just ran into the same issue as @Sigurdur_Herman and I was really scratching my head (on a deadline!) of how to get around it. You just saved me so much time and stress!!

Thanks so much, this worked for me. I'm now struggling with scaling the automation and wondering if it's possible.

In my case, I have a table that has a status column and then I have a linked records fields for Languages. When the status changes to 'Received', I want 3 languages to be removed. This system works with one language fine, but with 3, after the automation runs, the 3 languages get removed, but then repopulate (in reverse order).

For the 'Find records' action, I have 'does not contain' then the 3 languages (separated by commas). Then the 'Update record' action is the same as the above recommendation. But no luck.

Hi,
I don't understand all of your config, but  'does not contain' then the 3 languages (separated by commas) 
is not correct. You should add 3 different expressions
...and   ....blah_blah...
and {pri_lang}_does_not_contain   Language1
and {pri_lang}_does_not_contain   Language2
and {pri_lang}_does_not_contain   Language3

{pri lang} - primary field of a languages table

oh, thank you! such a simple miss...works like a charm now.