Hey Riccardo
My solution to this involves two steps
- An “Automation” in Airtable (which may need to be manually configured and must be manually turned on upon the creation of each base) which sends a webhook to make containing:
a trigger (time, upon certain field update, etc.)
a scripting block which sends either a webhook URL or JSON response to make, containing
-recordId
-baseId
-tableId(s)
-the make webhook URL
the recordId can be passed through via the trigger
the baseId can be determined easily via the script
the tableIds can be determined by either:
A) a custom text input in the input.config name (ex. ‘preRecordedTableName’) and then you can use the script to pull the table id of the table named ‘Pre-Recorded Videos’ (or whatever else you specifically call it in this base).
OR
B) something hardcoded into the script that pulls the table named ‘Pre-Recorded Videos’, if your bases ALWAYS have a table named Pre-Recorded Videos
Here’s an example of the automation as well as the script text :
let inputConfig = input.config();
let preRecTableId;
try {
preRecTableId = base.getTable(inputConfig.preRecTableName).id;
console.log(preRecTableId);
} catch (error) {
console.log(`The table ${inputConfig.preRecTableName} was not found.`);
}
const jsonBody = {
"baseID": base.id,
"preRecTableID": preRecTableId,
"recordID": inputConfig.recordID,
"assetFolder": inputConfig.assetFolder
}
const response = await fetch(`${inputConfig.hookURL}`, {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify(jsonBody)
});
As you can see, I also pass the value through of the field {Asset Folder} as it helps determine the route in my specific scenario. You could delete that piece.
- Once you’ve set up the proper payload from airtable, I use the webhook module to receive the payload from the scripting block, and the ‘Make an API call’ Airtable module in Make to update the record.
The beauty of this system is that I can have a single Make scenario for all operations of this kind, across all bases for each client. It’s a huge timesaver for creating and troubleshooting, and it’s elegant, to boot.
If I needed to use this across different clients, I could, en-masse, change the Personal Access Token aka “Connection” at the top of all airtable modules in the scenario(s), using something like this from weblytica.
A downside of the “Make an API call” module vs the “Update a Record” module is that, in the ‘Make an API call’ module, it is possible to attempt to write to an Airtable field that does not exist in the table, which would throw an error.
In the “Update a Record” module, which you are using in your video, Make loads the fields of that Airtable table, so it’s impossible to write to a non-existent field, but, as you’ve noted, it has the key downside of clearing all mapping when you switch to a new table.
Let me know if you have any questions, or if it would help for us to get on a short call.
-Paul
jpaulgale@gmail.com
