What is your goal?
To update a linked record record in Airtable with two different variables, where either one can be empty.
What is the problem & what have you tried?
I get an “[422] Value “” is not a valid record ID.” error for the whole bundle if either of the variables are empty.
I have tried to enclose the fields with “ifempty” and filled the B-slot with “empty” and “erase” to send a null value to Airtable, but it gives the same result.
A related question: how can I unlink a linked record with this same update procedure? Within Airtable sending and empty variable to a linked record field empties it, but not here.
Screenshots (scenario flow, module settings, errors)
That 422 happens because Airtable is receiving "" as one element of the linked-record array. A linked-record field accepts only valid record IDs (rec...); empty or erase cannot sit beside a valid ID.
The reliable pattern is to build the array before the Airtable module:
- both present →
[A, B]
- only A →
[A]
- only B →
[B]
- neither → omit the field to preserve existing links, or send a truly empty array if the intention is to unlink everything
In Make, the most debug-friendly version is: candidates → Iterator → filter out empty values → Array aggregator → map the resulting ID array into Airtable. With only two inputs, four router branches are also perfectly reasonable and easier to inspect.
Are A and B already Airtable record IDs, or are they names that still need a Search Records step? If you paste a redacted output bundle, I can show the exact mapping shape.
Thank you for your reply. That’s a bummer that Airtable won’t accept “empty” or “erase”. I had found this “ifempty-erase” solution in an old Airtable thread (https://community.airtable.com/other-questions-13/is-there-a-way-to-clear-empty-a-field-with-a-zap-update-15963), where it’s written as if it should be able to handle linked records. Is that info incorrect or oudated?
I can see how to employ a 4-way router for the separate cases with “data exists” filters between it and the update module.
If the candidates → Iterator → filter out empty values → Array aggregator → map procedure is better I would appreciate trying to learn it. However, must confess I’m a Make newbie and am somewhat bewildered by the architecture. I have done a fair bit of automations in Airtable and Zapier, but Make feels very different.
The current setup is Airtable search → Iterator → Iterator → Airtable update (-> Skip for error handling). This is due to needing to parse first days, then events for those days (linked records). This I had to ask about in this post ( Airtable update record updates only first item in array in a Bundle ) with the solution with two Iterators after each other was provided. I must admit I don’t exactly understand what the Iterators do.. 
.
I already have the record IDs to update (users to events), but may need to add an extra search step to find out the Airtable user record IDs. I currently work with an abstraction user that I have created separately, to be able to filter out inactive users in different forms and views.
To return to the question of deleting linked records, how does that play out here? If A has been linked before but then gets deleted in the original setting so that it would need to be updated by this scenarion (to unlink the linked record), how would one do that? Isn’t that what ifempty/erase is for?
Cheers,
Björn
PS. I didn’t understand what exactly you meant with a redacted output bundle? From where, all modules, or?
Thanks, Björn — the old advice is not entirely wrong; the key distinction is where erase is applied.
erase (or a true empty array) can clear the entire linked-record field when it is mapped as the value of that field.- It cannot be one element inside a list that Airtable expects to contain only record IDs. If Make sends something equivalent to
[recA, ""] or [recA, erase], Airtable validates the second item as a record ID and returns the 422.
- To remove one link but retain another, send the complete replacement array containing only the IDs that should remain. If none should remain, clear the whole field.
For two candidates, I would actually use the four-route version because it is easier to understand and maintain:
- A + B → send
[A, B]
- A only → send
[A]
- B only → send
[B]
- neither → clear the entire linked-record field with
erase or a true empty array
The Iterator/filter/Aggregator pattern becomes more useful when the number of candidates is variable. An Iterator turns each array item into a separate bundle; your two Iterators are expanding days and then the events within each day. An Array Aggregator does the reverse: after empty candidates are filtered out, it collects the surviving record IDs back into one array for a single Airtable Update.
By “redacted output bundle,” I mean: run the scenario once, open the output bubble of the module immediately before Airtable Update, copy its output, and replace real names/record IDs with fake values. You do not need to share every module. A screenshot of the linked-record field mapping in the Update module would also help. With those two items I can show the exact router mapping without needing access to your scenario.
Thanks Parsewell. First the ifempty/erase question, because if that would be solved perhaps the case would be solved also.
The way I understand your explanation is the way I think I have it. This is the output from the update module, where I for the first field to be updated have ifempty/erase in the mapping setup.
This is the way I have it set up. Nevermind that I don’t have “erase” also in the second field’s setup, this is for testing different ways).
Isn’t this just like you explained it, that it is “erase” for one full field?
Cheers,
Björn
Yes — the screenshots reveal the exact issue. The erase pill is not currently applied to the whole linked-record field.
In the mapping screenshot, Map is off, and the formula sits inside Record ID 1. That item is a single record-ID/string parameter. Make’s documented behaviour is type-dependent: erase on a string becomes null, while erase on an array becomes []. Your run output confirms this: the linked-record array contains item 1: empty, and Airtable then reports Value "null" is not a valid record ID.
So the current request is effectively sending [null], not an empty linked-record array.
For the route that must unlink everything:
- Turn Map on at the header of that linked-record field.
- Map
erase as the value of the entire array field, not inside a Record ID item.
- Because the target is now an array,
erase should resolve to [].
For routes where IDs exist, either map an array containing only valid rec... IDs, or keep Map off and add one/two Record ID items with the raw IDs — but do not put ifempty(...; erase) inside an individual Record ID item.
Since your two linked fields can apparently be empty independently, the four combinations are still the clearest setup: both IDs, first only, second only, and neither. The “neither” route clears both fields at array level.
Make documents the type behaviour here: General functions - Help Center
If you can post one screenshot after switching Map on for the linked-record field, I can confirm that the pill is now at the correct array level before you run it.
Thank you. I had not understood what the “Map” switch does, need to study the documentation for it. I have now activated it for both variables, like this:
With these settings I seem to have the scenario do what I wanted, even without using 4 different routes.
When I tested adding and removing linked records in the source table, the scenario beautifully added and deleted linked records in the target table. No errors, it just seems to work just like that.
Am I missing some testing cases, since you still said that I would need a 4-way router? The use case is simple in that way that this is always oneway. The target table is not updated for these fields any other way than with this scenario. In case the makes a difference.
Cheers,
Björn
You are not missing anything — if this mapping now passes the cases you tested, keep the simpler one-route setup.
My four-route suggestion was the conservative fallback for cases where Make sends an invalid single-item array instead of clearing the whole linked-record array. With Map enabled and ifempty(...; erase) applied at the field/array level, your current setup can handle the empty and non-empty states correctly.
I would only run these final checks:
- both linked IDs present
- only the first present
- only the second present
- neither present
- replacing an existing linked record with a different one
Since those target fields are written only by this scenario, there is no manual value to preserve, so the router is unnecessary here. Your simpler setup is the better solution. Nice work.
