Hi everyone! We’re excited to announce a new beta feature for the scripting block: script settings! With script settings, you can define settings for your script: a title, description, and settings items (table, field, view, text, number, and select). From your definition, we render a settings UI. Users of your script can update the settings and run the script without needing to modify the code.
You can sign up for the beta via this form. You’ll only be able to use script settings if you’ve signed up for the beta: if you’d like to test it out with your script users, please have them also join the beta. Please submit any feedback/issues here. Read on for more information about how to use script settings!
To start using script settings, add an
input.config() call to the top of your script. Use it to specify the various settings for the script.
Five types of settings items are available: table, field, text, number, and select. The values of the settings are accessible as properties on the object returned from the
input.config call, and can be used in the rest of your script. Settings items can optionally have a label and description that will be displayed in the settings UI.
The settings values are persisted between runs and shared between users of the block. You won’t be able to run the script if the settings definition in your code is invalid, or if any settings are missing values in the UI.
Script settings are completely defined within the input.config call in the script’s code, so you can share your scripts with settings via copy-paste. The settings UI will appear after the code is pasted in.
Refer to the in-block documentation or the API reference for full details about how to use script settings. The documentation will only be visible after you’ve signed up via the beta form. At this time, script settings are only available in the scripting block and not available in automation scripts.
Question - do the Table and Field pickers reference their objects by ID, such that changing the name of a Table/Field won’t disrupt the script’s operation if they are set via these input settings (like Airtable’s other blocks)?
If so, this could be a great way to add stability to my everyday scripts where I have referenced tables and fields by name rather than ID… Since I use the native app, rather than the web app, I have mostly referenced things by name, out of laziness. Getting to the ID’s is too much of a hassle :grimacing:
Fantastic! This will be great for me for doing bulk data updates from webhooks. I use a lot of Buttona to call scripts for individual records, but I can use the settings to filter HTTP requests for grouped data.
Are there plans for a date/time selector? I have several scripts that pull in snapshots from security cameras, and having a date/time picker here, rather than one I set on the record before launching via button would be handy and persistent across records.