I’m stuck with what feels like a hard limitation and want to confirm if there is any supported workaround.
Setup
I have a 1‑row helper table called Operaciones query.
In that table I do all the logic using:
Conditional Relations
Joined List columns
A JavaScript (Experimental Code) column
The outputs I need (lists of cleaners, counts, etc.) only exist thanks to those computed columns.
What does work
If I open the Data Editor, go to Operaciones query and click Export, the CSV I download includes the correct values from those computed columns. So Glide can compute and export them in that context.
What I’ve tried that fails
Scheduled workflow + Set Column Values
Trigger: Every X minutes/hours.
Steps: Query Operaciones query → Loop → Set Column Values (copy from JS / Joined List into basic columns).
Result: I get the red warning:
“This scheduled workflow uses unsupported Experimental Code columns.”
The Set Column Values step writes nothing; the basic columns stay empty.
The generated CSV/JSON has all the columns present but the values from the JS / Joined List columns are empty.
Workflows in general
Any workflow that is not triggered directly by a user action (button, etc.) seems to treat my JS / Joined List columns as unsupported Experimental Code and gives me empty values.
So right now, the only way I can get the data out is:
Manually open the Data tab → go to Operaciones query → click Export → download CSV.
**
As you can guess, this is not optimal as i need this information downloaded on a daily basis
**
Any official clarification or known patterns would be really helpful. Right now the difference between “manual Export works” and “all automation paths return empties” is driving me crazy
What’s most likely happening is that JS columns can only be evaluated client side. The reason for that is because running random JS server side could be dangerous and a big security risk due to potential SQL injection risks. In reality, the backend that Glide uses might not even be allowed to run uncontrolled JS. You might have to change your flow to write the JS column value to a basic column client side so your server side workflow can work with the written value instead of a computed JS value that probably isn’t allowed to run server side anyway.
I can’t write the JS column value to a basic column on the client side, because when I use the “Set column values” step it doesn’t work either. The basic column receives nothing, so it stays empty.
I’m seeing the same behavior with the Joined List column. I get empty results both when I use the “Create CSV file” step and when I use “Set column values”.
Is there any workaround?
I’m also really curious about the logic behind this in Glide. It feels like 90% of the data that lives in Glide’s tables (all the computed stuff) can’t be downloaded or used in automations.
You mentioned the Set Column “step”. Is that a step in your server side workflow? If so, that is not handling it client side. That’s still running that set column step server side, so it doesn’t change the result. You would still need an action executed client side by the user to write the values into basic columns. Maybe part of your app flow so it’s stored long before your server side process even runs.
Same question as above. Are you actually running these step server side or client side. And another question, what is the joined list derived from? Is is computed based on the javascript values that are giving you problems? If so, it just a trickle down effect. The joined list can’t give you anything if the source values can’t be calculated.
Making the user do something client side to write values into basic columns before your server side workflow even runs is the workaround.
You have to remember that computed column values are not stored values. They don’t exist in a database like basic columns do They are computed in real time as needed by the user’s device. Either the end user is computing them on their device, or the server does it as it’s running server side workflows. When it comes to running things on the server, you are going to have a strict environment and strict conditions imposed by the server, like not being able to run injected code from outside users. You are going to be constrained by the server not having access to user specific values or row owner information because the server does not run workflows as a specific user. Also the server is only going to be able to run based in it’s own clock time, which is typically UTC time, meaning computed values derived from current time might produce results that differ from what you get in your local timezone. Basically you are running code on someone else’s computer and they are going to have strict limitations on what you can or can’t do.
