The only reason I can think of that an App formula for a column of the same row wouldn’t update is if you updated a slice of the row that did not include the column with the App formula.
To clarify, I’m not using a slice — the Bot is acting directly on the main Event table.
As a test, I added a column called [Update on] with the simple formula NOW() as an App formula.
When the Bot updates a value (like [Work Status] = “pending”), the [Update on] field does recalculate as expected — so I know that the Bot is triggering a data change and the row is being re-evaluated.
However, I also have another column in the same row with this App formula:
This column does not recalculate, even though the row is updated by the Bot.
So it seems that App formulas which depend on external tables (like Contract) do not automatically recalculate when the current row is modified — unless the formula directly references fields that have changed.
Let me know if this is expected behavior or if there’s a known workaround other than converting the column to virtual or computing the value via Bot logic directly.
if I expose the same action used in the Bot (the one that sets [Work Status] = “pending”) as a visible button in the app and tap it manually, the [Surname] field does recalculate correctly — the SELECT formula updates the value as expected.
So it seems that the manual interaction somehow triggers a deeper evaluation or refresh of App formulas than when the same logic is run inside a Bot.
I double-checked, and there are no security filters applied to the Contract table or any other table in the app.
The table is fully accessible, and the SELECT() expression returns the expected result when triggered manually via a button action.
So the issue seems to occur only when the same action is triggered from within a Bot — in that case, the [Work Status] value is updated correctly, but the App Formula that uses SELECT(…) from Contratti does not recalculate, even though the row itself was clearly modified.
Let me know if there’s anything else that could cause this behavior on the server side.
it does recalculate properly, even when triggered by the Bot.
Of course, it returns the full list of all surnames, as expected, but the key point is that this simplified SELECT does get re-evaluated, even in the Bot context.
So it seems the issue is not the SELECT function itself, but possibly how AppSheet optimizes or skips reevaluation when the expression includes IN(…) or references to specific row conditions.
Let me know if you have any further thoughts — this test was really helpful to isolate the issue! Or some workaround
So.. it’s your IN() that doesn’t find any rows when triggered in Bot. Don’t know in which table your columns are, but it might be that you need to use [_THISROW].[ColumnName] with either of them.
The value correctly appears after I manually edit/save a row, but then disappears in the table view shortly after, especially after a sync. So the virtual column doesn’t persist or trigger correctly after server-side updates.
I also tried having the Bot explicitly write the value to a physical column via a Set the value of a column action using the same formula — but, that doesn’t work either when triggered via the Bot. The column remains blank or unchanged.
The only time everything works as expected is if I manually trigger the action from the UI (e.g. via a button). In that case, the value is computed and written correctly.
It really seems that the SELECT(…) formula involving SPLIT and IN across another table doesn’t reliably resolve when executed in a server-side Bot, even when writing the result directly.
Any further insight or workaround would be really appreciated. Thanks again!
Can you swap your AND() parameters for this and see if it works?
AND(CONTAINS([Event N.],[COD. EVENT]),[Status lettel] <> “CXL”)
Keep the Select statement the same.
I can confirm that the version of the formula using CONTAINS() works correctly — the value is now updated as expected both in a virtual column and in a physical Text column, when the Bot updates a value in the same row.
So the server-side update now successfully triggers the formula evaluation.
The only limitation I noticed is that CONTAINS() may return a match even when it’s not an exact code match — for example, if [COD. EVENT] = “A187”, it will also match rows where [Event N.] contains “A1871”, “A1872”.
This is something to keep in mind, especially if your codes share common prefixes.
So, your original formula is probably failing due to the way you are splitting the text up around the comma. You should probably investigate just exactly how your text string is being stored on the backend. Are you sure the string is separated exactly by commas…or is it space comma space or comma space…something like that?
I think the front end string parsing is more lenient than the backend one?
There is no reason to split an EnumList value; IN([COD. EVENT], [Event N.]) will work just fine. If you feel you need to split it for some reason, read the SPLIT() help page for help, as this is a common point of confusion.
Since [Event N.] is now an EnumList, there’s no need to treat it as a text string — IN() correctly evaluates it as a list.
However, when I first wrote the formula, [Event N.] was just a plain Text column, so SPLIT() was required at the time.
That said, I still think there’s an issue in AppSheet:
If you use IN(…, SPLIT(…)) in an App Formula (even in a physical column), it does not recalculate the value when a Bot updates the row — even though the logic is correct and it works in manual edits.
So even if the structure is valid, using SPLIT() inside IN() causes the formula not to update properly when triggered by a Bot.
This feels like an internal evaluation inconsistency and might be worth reporting as a bug or limitation.
