Help

Re: Automations: inputs are unexpectedly null

1893 1
cancel
Showing results for 
Search instead for 
Did you mean: 
chetem
6 - Interface Innovator
6 - Interface Innovator

Hey everyone, I’m using Airtable’s new built-in automations feature but am running into some trouble. The first major roadblock is that my input variables are “null” even though there’s data in the actual field. I know this feature is new, so I’m actually thinking this is a bug but has anyone else had similar issues? When I run a test, sometimes my input variable doesn’t even show that it exists! I’ve attached a screenshot to show what I mean.

CB47D2A8-8920-4494-8348-10C289BF183C

I’m also getting inconsistent results with my fields and the values they have once brought into the code editor. I’ve had a situation where 2 identical fields (rollup fields configured to be the exact same thing) were brought in as input variables but one was an array with only 1 item in it (all of the values were mashed together as a single string) and one was an array with all the items as individual values in the array (which is what I would expect and want to happen). Anyone else getting inconsistent results like this? It’s making it really hard to work with!

Thanks for any help!

12 Replies 12

Thanks guys. I am using a New Record trigger so it’s possible that’s part of it. But when writing code and testing, the sample record I’m going off of (i.e. the very first record in the base) is fully populated. It’s possible I’ll run into issues when this is “live” with the data not being there in time, but for testing purposes all of the data is there and should work – testing the script itself pulls data from the previous step (i.e. the new record trigger) which was also manually forced by testing it. Perhaps fetching the record data within the script is the safer option anyway.

Regardless of that, there’s still something funny happening here because top 1 and top 2 conditions are exactly the same but behaving differently…

At this point, I suggest making a copy of your entire base, and doing more detailed testing using that duplicate base. Make some new records and run some rigorous tests. Put it through its paces in the same manner that you plan on using it when it’s live. I believe that this next level of testing will tell you more about the system’s behavior and the actual data being passed into the automation. From personal experience, I know that I’m a lot more cautious about messing up my data if I’m making a big change directly in the main base. I tend to feel more free to play and explore and really troubleshoot things if I’m working in a duplicate. Something tells me that you’ll find solutions more quickly this way that you wouldn’t by working in your main base.

Thanks Justin, that’s a great idea. This base is brand new and still in the “play” stage so have been making adjustments no problem. I’ve switched to fetching data from within the script which seems to be working better. I’m still curious about the strange behaviour described above and what’s causing that (i.e. whether it’s expected behaviour and why, or if something funny is actually happening with it still being in beta). Either way, I’ve moved on to other solutions which has been so far so good. Thanks again for all your help!