Well, the trigger only fires if both columns have been changed at the same commit. If you change only one column the trigger does not fire because the other column is still the same.
Since you are checking if both columns are NOT EMPTY you could add a third formula column which checks if both columns are NOT EMPTY and returns the value TRUE. So if both columns now have values that third column value has changed where you can put a trigger on.
Formula of column “changed”: and(not(isempty("Name")), not(isempty("Second column")))
Actually, I find the behaviour strange though. Why is a rule not checking all its filters on each and every commit?
But then, if I switch the rule to a periodically one and fire it manually, it checks out ok.
Yet, i cant use a periodically one, as those cant change data fields… it’s a mess. Will try your solution now and report back.
No, it does not check out. It seems, that the checking of the filter value is not started at all, if the data is, or derives from link columns. This is the filter now:
If I convert the rule into a periodically one and fire it up manually, it works. So the filter is fine. Point is, filter is not checked at all after commit, as it only derives from changes in link columns and formula columns.
If changed to a periodically rule and filter check is forced either by clicking “do now” or by the time event, it works.
Well, i could work with that, if only periodically rules could also alter data, so I could set “message sent” to true… argh
Same is true, if I include a column with real data, like a file or a text value into the filter and change that. Then the event is fired correctly, and the filters are checked just fine.
Maybe there is a bug with the periodically and manually check, I don’t know. Those are internal logics I cannot explain.
Yep, there are no filter column to watch, it would be a big improvement though. But since you could put a trigger on the two other columns you should be fine. But you have to check the third column if it is true to make sure the trigger only fires if both column have values.
Indeed. For the formular coloumns, I already suspected, that the “client based character” of those would prevent filter usage. For linked columns, that seemed off.
I heared, that the filter watch for link columns should come in one of the next updates. So will see how it goes.
Formula columns could be watched too, if the backend would create text columns to hold the calculated data in it. Surely, there is not one formular column, that changes every second and would overload seatable servers… one could even check, if the browser calculated value still matches the one, loaded from backend and only change if not… but yeah, future music.
Or one could compute them server side, if used in automation rule filters, as the given formulas are stored on the server, right? ^^