Bot updates a row, but App Formulas on the same row are not recalculating, how can I force it?

[C2]

Hi everyone,

I'm running into a problem where my App Formulas are not recalculating even after a Bot updates the row.

Here’s the situation:

• I have a Bot that runs when a certain condition is met in Table A.

• The Bot performs a “Run action on rows” to update a value in Table B (e.g. [Work Status] = "pending").

• The row is definitely being updated — the change is visible both in the UI and the backend (Google Sheet / SQL).

• However, an App Formula in another column of that same row does not recalculate automatically.

For example, I have an App Formula like this:

SELECT(
Contract[Surname],
AND(
IN([COD. EVENT], SPLIT([Event N.], ",")),
[Status lettel] <> "CXL"
)
)

This formula used to recalculate when the row was edited by the Bot, but now it doesn’t anymore. 

If I manually click edit/save on the row the formula works correctly.

I’d like to ask:

• Is there a way to force App Formulas to recalculate after a Bot edits a value of the row?

• Could this be related to sync settings, server caching, or app performance options

• I tried to add an [UpdateTrigger] column and set a groped action, but didn't solve the problem

Thanks in advance for any advice!

[Steve]

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.

[C2]

Thanks for your reply!

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:

SELECT(
Contract[Surname],
AND(
IN([COD. EVENT], SPLIT([Event N.], ",")),
[Status lettel] <> "CXL"
)
)

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.

Thanks again for your help!

[scott192]

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.

[C2]

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.

[AleksiAlkio]

By any chance you have a security filter in your Contract table that filters the data when triggered in the server side?

[C2]

Thanks for the suggestion!

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.

Thanks again for the input!

[AleksiAlkio]

What happens if you use just a simple expression SELECT(Contract[Surname],TRUE) with your Bot? Does it work properly then?

[C2]

Thanks, I tested your suggestion.

Yes — when I replace the formula with:

SELECT(Contract[surname], TRUE)

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

[AleksiAlkio]

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.

[C2]

I tried to use also _this row but nothing .

[Steve]

Do you have Delta sync enabled?

If so, disable it.

[C2]

Thank you for the suggestions so far.

I’ve now tried all the following approaches, and here’s a detailed summary:

- I disabled Delta Sync, but it didn’t change anything — the formula still doesn’t recalculate after the Bot runs.

- I created a Virtual Column using the same formula: 

SELECT(
Contract[Surname],
AND(
IN([COD. EVENT], SPLIT([Event N.], ",")),
[Status lettel] <> "CXL"
)
)

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!

[C2]

Thanks everyone for the help.

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.

[scott192]

It shouldn't return a match for A18...?  Are you sure?

[C2]

exactly 

[scott192]

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?

[C2]

Thanks for the suggestion!

Just to clarify:

[COD. EVENTO] in the Eventi table is always a single unique value like A12, A145, A1234, etc.

On the other hand, [Evento N.] in the Contratti table is an EnumList, containing multiple values like:

A129,A328,A57

A556,A55,A354

A853,A851,A52,A2343

So the values are stored as a single string separated strictly by commas with no spaces.

I've double-checked in the backend (Google Sheets), and the values are always saved like "A123,A124,A125" — with no extra spaces or line breaks.

Let me know if you think there’s anything else I should test!

[Steve]

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.

[C2]

You’re absolutely right — I’ve now tested it and this version:

SELECT( Contract[Surname], AND( IN([COD. EVENT], [Event N.]), [Status] <> "CXL" ) )

works perfectly, without needing SPLIT().

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.

Thanks again for helping clarify this!

[Steve · Accepted solution]

---

@C2 wrote:

This feels like an internal evaluation inconsistency and might be worth reporting as a bug or limitation.

---

There are several such inconsistencies, unfortunately.

Reporting this as a bug is pointless: Google doesn't seem to care about components they aren't actively working on. They finished bots several years ago. Bots and Automation was largely developed by developers new to AppSheet and conflicted with existing behavior in several ways.