Automations: inputs are unexpectedly null

What type of field is producing those null results? It may be something to do with the field type.

To your other question, I haven’t yet seen inconsistent results with data coming in. Then again, I haven’t tried bringing in data from rollup fields. Could you post screenshots of your rollup field setups? You say they’re identical, but it would still help to see exactly what you’re doing.

Thanks for the response Justin. Here’s a couple screenshots of the 2 different fields. .

I’ve also had a field work in one script, but not another one so really thing there’s a but of some sort especially with it still being in beta. But if there’s something I’m missing here, I’m all ears!

And just to be consistent with using the “Top 2 Condition Foods” field, here’s the relevant screenshots (though I’ve had issues with all of them but only some of the time)

Thanks for sharing those details. The setup looks good, but one thing that sticks out to me is that the data you’re pulling is coming from a lookup field. Lookup fields most often create arrays, even if they’re only pulling from a single linked record. To give you an example of how that comes into play here, let’s say that you’re rolling up from three records, and each lookup field is in turn pulling from one other record. Looking at those lookup fields directly, what you see might look like this:

Apple
Pear
Banana

But what’s actually being stored under the hood is a single-item string array in each record, which would be represented like this:

["Apple"]
["Pear"]
["Banana"]

When the rollup field pulls in those lookup values, it’s not grabbing the string inside the one-item array, it’s grabbing the array itself. Therefore, the values item that you use in the rollup isn’t this:

["Apple", "Pear", "Banana"]

It’s actually this:

[["Apple"], ["Pear"], ["Banana"]]

What the ARRAYCOMPACT() function does is try to strip out empty items from an array. However, it’s looking for null-equivalent individual data values. If, for some reason, you have an empty array coming in:

[["Apple"], ["Pear"], [], ["Banana"]]

It’s probably not going to be stripped out, which may be how you’re still getting null values in your script.

I suggest changing your aggregation formula in the rollup field to this:

ARRAYCOMPACT(ARRAYFLATTEN(values))

ARRAYFLATTEN() will get rid of the array nesting, and then ARRAYCOMPACT() can take care of any null values. Let me know if that helps with how the data comes into your script.

Apple
Pear
Banana

["Apple"]
["Pear"]
["Banana"]

["Apple", "Pear", "Banana"]

[["Apple"], ["Pear"], ["Banana"]]

[["Apple"], ["Pear"], [], ["Banana"]]

ARRAYCOMPACT(ARRAYFLATTEN(values))

Hey Justin, I really appreciate you taking the time to respond. I have found it a little difficult working with arrays as behaviour is often different than I would expect. For example, working with linked records return the objects as an array and when viewing the base itself you see all objects by name, but when using that same array in the script editor they’re actually pulled in as an array of IDs and any filter logic etc would never work – that took me a while to figure out but is why I eventually went with the look up field instead.

Long story, short I understand what you’re saying and believe you are correct about flattening the array. However, I’m still getting funny behaviour…

Here I have 2 fields configured the same way in the manner you suggested:

I then went into the Automation code editor to see what values I’d get through and here’s my results:

– The input variables on the left are just there to show that I have in fact connected to the correct fields.
– The script input (top right) doesn’t even show that all of the variables are there (i.e. top2ConditionFoods isn’t even showing)
– When using the editor, I get autocomplete when typing top2ConditionFoods but again it’s competely null

Any ideas?

@chetem What trigger are you using for your action? Are you using Airtable’s “New Record” trigger?

I was about to ask the same question as @ScottWorld. Even if you’re using a record entering a view as the trigger, the specific timing of that trigger may not be when you think it is, and there may be data missing at the time of the trigger that only appears a second or two later after Airtable finishes refreshing things. In other words, what’s sent to the automation is the data in the record at the exact moment it triggers, but some of that data may not be fully refreshed/synced until after the automation has already started.

One alternate way of approaching this is to not pass record data directly into the script via the input variables, but to let the script retrieve the data from the record. Because there’s often a slight delay in launching the script (which you’ve probably noticed during testing), that should let the record data “settle” before the script retrieves it.

As an aside, I noticed that you use let for the first variable assignment, but var for the rest. I’m still picking up on the difference between the two (and const) in terms of how the script handles them, but most scripts I’ve seen (and written) for Airtable use let for everything. I doubt that would be the determining factor here, but you might try switching and see if anything changes.

@chetem:

Yes, as @Justin_Barrett mentioned above, I was going to caution you about using Airtable’s “New Record” trigger.

In general, I feel like Airtable’s “New Record” trigger should typically be avoided in the majority of use cases, because it triggers as soon as the new record is created.

What this means is that in the vast majority of cases, the new record is still completely empty — with no data in the record at all — when the trigger happens.

In my ideal world, the “new record“ trigger wouldn’t trigger until the new record is SAVED (i.e. the user is done doing data entry and they’ve moved onto another record), not as soon as a completely blank record is created.

Now I haven’t tested this myself yet, but from anecdotal comments here on the forum, it seems like the “New Record” trigger works well for form submissions & new records that come through the API, but definitely don’t quote me on that. :stuck_out_tongue:

In any case, it seems like the reliable trigger that you can depend on is the “New Record In View” trigger, because you can control when a record enters the view.

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!