Field Permissions: No edit privileges except for Scripts/Blocks

[Kamille_Parks]

Certain blocks require users add an editable (non-formula) field to a table to hold misc data which shouldn’t be directly edited by the user (i.e. the Map Block requires a geocache field). Many Script Block scripts semi-automate or standardize data entry processes to provide a form of data validation or workflow integrity.

I think it would be nice if Airtable’s field permissions included a toggle for " Allow this field to be set in scripts/blocks/API" when the field permissions are set to: “Who can edit values in this field > Nobody”. For fields with permissions set to “Who can edit values in this field > Nobody”, there is already a toggle for “Allow this field to be set in records created through forms”, this would work similarly. This will help collaborators who should have the ability to edit data as determined by the script/block do so, but not directly to enforce some measure of data consistency in all the cases where a Formula would be insufficient.

[Michael_Andrew]

Upvote!

Script / Automation Permissions Scripting app

I am wondering how permissions work with scripts and automations. I have gotten errors in my automations, that the script won’t run because of insufficient permissions. I assume it is because I had set table or field permissions about who can edit them. I assumed that automations could run under any permissions, but it’s clear it cannot. Does anyone know what must the permissions be at table and field level for automations to work correctly?

[jowan_qupty]

BIG +1 from me on this feature.

This would come in very handy when you don’t want base users to mess with the content or structure of your base, but would still allow them to add/edit/delete records through the scripting block, therefore enforcing your desired business rules.

[jowan_qupty]

Just Noticed that there is a permission option to allow the record to be edited through automations.
Wondering if Airtable is also going to add this feature to the scripting block??

Also if this means that they create a permission to allow the script to create new records?

[Maxim_KM]

Stupid, but it doesn’t allow Scripts to work with these fields. However, this is almost the same(I mean Automation and Scripts)

[Shaun_Walker]

Big +1 on this.

I’ve been rolling out scripts left and right and keep getting tripped up (forgetting) by the fact that the field permissions prevent a user from running a script the writes to said field. My use case is pretty basic, too: I’ve got a Record Status = (Active | Inactive) field which we use to drive record visibility in filters 'n stuff. Only I can modify this Record Status. And as a result a script that adds new records, with Record Status = Active, won’t run for anyone but me, since I’m the only person with the edit permission on that column. Seems like my options are to:

• Replace my Active | Inactive select field with an opt-out system such that scripting won’t need to edit the field (e.g., undefined/null == Active, Inactive == Inactive). I don’t really like this option because it’s less explicit.
• Add an automation that triggers when a new record is created that sets this value to Active since, as has been pointed out, field permissions can be overridden in automations, but not yet in scripting blocks. This seems a bit circuitous.
• Allow users to edit the Record Status field and keep the field hidden from all non-personal views and hope they forget about it