Automations: inputs are unexpectedly null

[chetem]

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.

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!

[Justin_Barrett]

chetem:

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.

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.

[chetem]

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!

[chetem]

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)

[Justin_Barrett]

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.

[chetem]

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?

[ScottWorld]

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

[Justin_Barrett]

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.

[Justin_Barrett]

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.

[ScottWorld]

@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.