Hi @Donat, thanks for the help. I was able to solve it using the following ways -
Issue - 1 : Text input and button onclick filter
Yes - The Setup
An action is used to handle a parallel activity, and the same button event also updates the filter variable which is used as a parameter to the object backing the object table. This was intentional — the setup ensures the user always has to click the button to see any changes. A “set variable” functionality is also used on that same button click.
The Blocker
When a text input was introduced — where the user enters new or updated text, wired to the button to filter the object table with that specific text — an issue appeared in view mode: the user has to click outside the text input first before the button click works. In edit mode it behaves as expected, but in view mode it breaks.
The Root Cause
The search text was being used directly as a parameter to filter the object table. This created an automatic update loop — the table would re-filter as the value changed, rather than waiting for the button click.
The Fix
To break this loop, the “Recompute variable value” was set to “only when triggered by an event” on a new dedicated variable. The search text now feeds into this new variable instead of directly into the table filter. Since this variable only recomputes on the button click event, the table is no longer automatically updated as the user types — and the button works in one click, even in view mode.
Solution - I reverted the Recompute variable value to on load and on trigger of an event and passed the duplicate variable which I updated on every set.
Therefore, decoupled the text input from the filter by routing through a controlled, event-triggered variable. The user — not the typing — drives the update.
Issue - 2 : I also encountred another “race condition” between variable set and action trigger.
Same setup as previous but here to the action I was passing a parameter.
The Setup
Multiple buttons each set a specific standalone variable (1 button → 1 string variable), with one shared/general variable tracking the current selection. On button click, the shared variable was updated and an action was triggered using it as a parameter — all in the same event.
The Blocker
The action always received the previous state of the shared variable — the “-1th” value — because setting a variable and triggering an action in the same event happen concurrently. The action fires before the variable has committed its new value.
The Fix
Remove the shared variable from the action chain entirely. Each button now passes its own value directly to the action as a parameter at the point of click — no shared variable needed as a middleman.
Im interested in understanding additional solutions for the same.
Learnings
Workshop events are concurrent, not sequential. When you set a variable and use it in the same moment, the order is not guaranteed. The solution in both cases is to break the dependency — either by controlling when a variable recomputes, or by removing the variable from the chain and passing values directly at the point of interaction.
