Is anyone experiencing sudden zap fails related to Airtable permissions?

I believe I have an error with respect to permissions. We have a zap that was happily updating a table column until we set up permissions on the table (insert and delete only for specified users). The zap now errors at this step with a 403. However, the user access that the zap uses has all required permissions. But also, we have tried all other combinations: remove permissions, use different user access in the zap, build a new zap step. Can any suggest?

Also, I haven’t raised a ticket in a while (ever?). Looks like that is not possible now. Pinned post here tells me to use in app help, but that just sent me to a bot that simply pushed some irrelevant Support Manual articles at me. Am I missing something?

We may be seeing similar issue. Let us know if you hear anything.

2 Likes

Hi, thanks for reporting this, we’re looking into it now.

Regarding the steps you tried to resolve the issue, can you clarify how you removed permissions – did you remove all of the locking restrictions across all of the fields in the table?

We have experienced the same problem recently. Trying to solve yet

1 Like

thanks @Kasra

re your question: the column that the zap is attempting to update actually had no permissions set on it. Ever, as far as I know. The table did though. It restricted both create and delete to specific users only. One of those specific users is the owner of the zap connected account. Also, btw this account is used in a number of other zaps which are running fine.

After more testing, @Kasra it appears to me that if you have restrictions on a Date field, then it causes issues with updating, even if you’re not updating that Date field. @Peter_Borg - do you have restrictions on a date field by chance?

Thank you for the additional information! We’re working on it now, will likely be fixed by mid next week. In the meantime, if you remove all field locks in the table, things should work again.

Thanks for kicking the tires while it’s in beta :slight_smile:

actualy no @openside, none of the date columns in this particular table have access restrictions, sounds like @Kasra 's people have identified root cause though