With these conditions, I basically try it one way, if it doesn’t work, I try the opposite. If that doesn’t work either, I scratch my head and wonder why :huh:
But look at it this way: my condition is “if TriggerDate is before now”. If you read it the other way around, it’s “now is after TriggerDate”, which means, the time has come. It works.
About using “equals” instead of “lesser/greater than”: if your scheduler for some reason doesn’t run on a given day (your server is down, for example) you might skip a record. Or if you change the server’s clock. The wider conditions cover this case.
A second case: if a user edits the TriggerDate of a record that was supposed to trigger tomorrow, but moves that date to “yesterday”, the “lesser than” will still catch it, whereas the “equal” will miss it.
These are rare cases but I think this way it is more robust. But it requires ensuring that it doesn’t run twice. We could use the “repeated runs” feature for that, but it might make it complicated to manage in the cases where we do want to trigger more than once, for some reason (re-send email?). We wouldn’t have a way of re-setting the system-managed “has already run” flag.
So I just leave repeated runs checked, making the system ignore repeated runs, and instead I use my own flag, a “processed” field, that I check as a condition (only run if processed = false), then set as an action (after processing, set “processed = true”). If ever I need to reset I just change that field back.
I hope this clarifies things. In case of doubt, just experiment!