Automation Expression Editor Updated Fields Empty Array

“Table record update.Fields” returns an empty array.

Seems broken. If I am misunderstanding how this is to be used can someone point me in the right direction? There seems to be very little documentation regarding the usage of expressions in the Automation Editor.

I have an automation that fires on Table record update when one of three specific fields are updated.

The automation should then set the names of the fields that changed in a column on the record that changed.

However, it results in a stringified empty array every time.

Has anyone else experienced this issue?

TIA

Did you try what happens if you dont use TOTEXT() but @Table record updated.Fields + '' instead?

Usually +'' should result in a list of words without " " and [ ] (top one on screenshot) and TOTEXT() includes " " and [ ] (bottom one on screenshot…

Hi Thorsten,

Thanks for the tip, I’ll try it, but the post is not about removing the square brackets, it’s about the lack of values.

There should be at least one value in the array if the automation is firing.

Yes I got that. I was just wondering if the is in the function or if there is really data missing. So I would just try if you get any data with +''

The rest is only for understanding the difference between the two.

If you get data with +'' it is clearly a bug in the function. Otherwise we need to find out why there is no data in this array…

I’ve updated the automation to use the concatenation method instead and it returns empty.

Hi Eric,

The Tulip Team looked into this and it appears when we added column filtering to Automations recently @Table record updated.Fields was unintentionally added, even though it does not contain anything (hence why you are seeing an empty array). We will remove this to prevent confusion in the future.

I don’t think there is currently a way to determine which field triggered the automation (and multiple fields could have changed at once).

A less elegant option, but you could create multiple automations that each trigger off one field.

Hi Beth,

That’s incredibly disappointing. Given that the Automation trigger itself is capable of detecting which columns had changes it seems a natural progression to leverage that same concept in a task.

We were counting on getting multiple values when more than one qualifying field is changed.

Unfortunately, most other approaches seem to incur the usage of many mor tasks and will effectively blow out the task allocation. As this is the pilot Automation project for the client we do not want to incur an automation add on until after they see a proof of concept.

We’ll still be using the automation to kick off a request to a connector function, but will unfortunately have to offload the rest of the functionality to the API it contacts.

Looking forward to seeing automations evolve, but for the moment their usefulness is limited.

I will of course created a feature request for @Table record updated.Fields to be added.

Please thank the team for me.