Skip to main content

Hi all,



I’d like to know if there is a way in a Scripting app to check if the script was called from the click of a button in a column or via the Run button on the Script app itself.



My use case is that we ideally want one script that can be used either for a single record (the button column scenario) or an array of records (which we would fetch & manage in the script itself).



Basically the first if statement in the script would check this, and then the code would branch accordingly. Sample code to demonstrate the idea:



let table = base.getTable('Orders');





if ('button was clicked') { // <-- How to make this check??





    //process that row only





    let record = await input.recordAsync('Pick record',table );





} else {





    // process records from a table or view etc.





    let records = await table.selectRecordsAsync();





}


Thanks in advance for any suggestions!

No, that currently is not possible.



As @kuovonne said, there isn’t. This is an obvious oversight that the designers should have considered. Lacking this capability, there is a way to get there and it’s yet another in the long list of Goldbergian buffoonery that more often than not, pervades the realm of Airtable solutions.





  1. Create the button and have it call a script block (A) that does one thing - and only one thing. It sets another field (like a checkbox).


  2. Create the script block (B) that when “Run” manually, it looks for any records where the checkbox is enabled and processes only those records selected (there should be just one as the next item will reveal).


  3. Create an action that fires script block (B) when – and only when – the checkbox has been enabled for a single record.




Steps 1, 2, and 3 resolve the first condition - i.e., when the button has been selected. Now we’re on to the second condition - when Script Block (B) is run manually.





  1. Process all the records when – and only when – no records were checked.




As @kuovonne said, there isn’t. This is an obvious oversight that the designers should have considered. Lacking this capability, there is a way to get there and it’s yet another in the long list of Goldbergian buffoonery that more often than not, pervades the realm of Airtable solutions.





  1. Create the button and have it call a script block (A) that does one thing - and only one thing. It sets another field (like a checkbox).


  2. Create the script block (B) that when “Run” manually, it looks for any records where the checkbox is enabled and processes only those records selected (there should be just one as the next item will reveal).


  3. Create an action that fires script block (B) when – and only when – the checkbox has been enabled for a single record.




Steps 1, 2, and 3 resolve the first condition - i.e., when the button has been selected. Now we’re on to the second condition - when Script Block (B) is run manually.





  1. Process all the records when – and only when – no records were checked.



But this doesn’t actually have a single script that detects if it was run from a button field or from the script app. It lets you reuse the code for one script in two places, but actually involves three scripts (one for setting the checkbox, one for running from scripting app, and the automation script.)



I suspect that you don’t expect anyone actually try to implement this “Goldbergian buffoonery”. There are too many reasons why this seems like a bad idea.

But this doesn’t actually have a single script that detects if it was run from a button field or from the script app. It lets you reuse the code for one script in two places, but actually involves three scripts (one for setting the checkbox, one for running from scripting app, and the automation script.)



I suspect that you don’t expect anyone actually try to implement this “Goldbergian buffoonery”. There are too many reasons why this seems like a bad idea.




The number of reasons this is a bad idea is irrelevant. It works.



The number of reasons this is a bad idea is irrelevant. It works.




Yes, I agree that it would work. But I fail to see how the pros would outweigh the cons.



Yes, I agree that it would work. But I fail to see how the pros would outweigh the cons.




I think you’re overthinking this - we all agree it’s not possible to do it right, but it is possible to do it. I think the customer - like many others building convoluted processes - will probably choose to use this or some other level of complexities that just get the job done.

Hi both, thanks for your thoughts and suggestions on this. It’s good to know both a) that it’s not possible using ‘out of the box’ functionality, and b) that there’s a potential workaround 🙂

Reply


Terms & Conditions