Today we had an issue where a few of our automations started failing due to all of our “Link to _” fields breaking. We have been using these fields as a main link between tables, and they have all started failing with the same error:
Field “_ ID” cannot accept the provided value: Cannot modify a computed field.
Does anybody have any idea what might have happened? This all started happening around 1:30pm EDT today, and it is not just one table, but at least 4 or 5 tables. Any insight into what might have happened would be very much appreciated. It is a very big workflow issue for our company as this drives a lot of what we work on a daily basis. Thank you!
Solved! Go to Solution.
There have been no changes. We have a base with 5 users and I am asking around as to whether any of them were on at that time, but I have specifically tried to add permissions to the tables so that I am the only one who is able to edit, and I was not online today.
I have contacted Airtable support, but I have not heard a response.
So to recap what I have found so far -
What was the field type before? Was the field a formula field?
What is the value that automation is trying to put in the linked record field? Does that value already exist as the primary field value for exactly one record in the linked table? If the value does not exist, and the primary field is a formula field, I would expect the automation to fail. If the value does not exist, but the primary field is a single line text field, Airtable would create a new record with the given value in the primary field.
The new entry is set on a trigger when the table with the primary row is created.
To explain the automation:
Once an entry in table A is created, create an entry in table B with “table A ID” set to the primary key (autonumber) of table A.
The error we are getting is:
Field “table A ID” cannot accept the provided value: Cannot modify a computed field.
Hey @kuovonne , I’m the product lead on this project.
The problem is that this automation was working, 100% correctly, for 3+ months. So all of your debugging questions, which we appreciate, will be answered in the negative. The automation worked according to spec for several months.
Specifically in response to your suggestion for debugging - the value already exists as value for one record only in linked table. That’s how the automation was able to work flawlessly for several months.
At the time of failure, no user was logged into Airtable and using the system. No new automations or changes were made. No limitations under our Pro Plan were reached. No erroneous record was introduced.
Yet this core automation broke, and our business can not function without it.
In order to debug, Jack, as he mentioned, changed the type of field from ‘Link to [table]’ to ‘single line text’, and this causes the automation to work. But then we can no longer do necessary operations in our workflow - we need to have the field remain a ‘Link to [table]’. So switching permanently to ‘single line text’ is not an option.
So the question is: what could possible cause a long-running automation to suddenly fail at a time when no users were logged into Airtable, no changes were made, and no limits were exceeded?
This is urgent as our business can not run.
I’m sorry, but I do not know what could cause a long-running automation to suddenly fail as described in this thread. As I suggested in my first post, I recommend you contact Airtable customer support.
This is a community forum where that vast majority of users are other Airtable customers (myself included). Airtable support will have access to inside information, such as whether or not Airtable changed anything behind the scenes (which it occasionally does without announcement).
When you contact Airtable support, you can include the URL for the automation in question. This support article describes the information that Airtable recommends including in your support request.
This seemingly fixed it!
Using the Airtable Record ID is working. We were originally using the autonumber type primary key in the “Link to record” fieldm, but now using the Airtable Record ID is working, and showing the primary key in the field. I believe in the past it would have shown the Record ID itself, the long string starting with
rec____, but it doesn’t seem to be anymore.
Thank you @kuovonne so much for the help! You are amazing!
I will keep in contact with the Airtable support to see whether they have changed something in how the automations work. This is a pretty big breaking change to our automations and I am surprised if we are the only case of it happening.
I’m having the same issue (my automation was previously working, then this problem occurred) but I can’t use this solution.
I currently have an automation that pulls in data from a google form, which then creates a new record in Table B. One column is the Primary key to Table A (i.e., one of the google form inputs is the primary key) , which was how I was linking Table B to Table A.
I’m doing something similar in another table to the same effect - now broken after having worked for months. Any possible fix here or update from Airtable Support?
So my automation flow is:
Trigger: Google sheets row is created
Actions: Create record (in Table B); the record fields are (all pulled from the new google sheets row):
The current error is ‘Field “Applicant ID” cannot accept the provided value: Cannot modify a computed field’
I’m not sure where I would use record ID here, could you clarify?
Thank you for the screen captures. It looks like your trigger is a new record in Google Sheets, not a new record in Airtable, so you do not have a record ID of a triggering record.
This scenario is a bit more complex than I can volunteer to troubleshoot over the forum right now. Hopefully Airtable support can give you some feedback on why the automations are no longer converting field data properly any more. It may be in part because the value is a number and not a string.