Action blocks (and all blocks, really) should be agnostic to the other blocks in the scenario. It should only care about the input fields, regardless of if they came from a date trigger or a column change.
That doesn’t mean that this request is irrelevant, just that we need to think about designing the feature in a way that “plays nicely” with the rest of the platform.
PS: Moved this to a new topic as it’s not super related to the previous one.
Yes, this is what I do.
I think that the trigger’s trigger should always be included in the payload without explicitly adding it to the recipe.
Something I definitely need is to know who changed a column value.
If I use the “When column changes” trigger, monday calls my action at every change.
The column can be changed by the user or by my app.
At the moment, this is risky because, if my integration changes a column which is the trigger for the same integration, it creates a loop, wasting all the available actions with just one click.
How I overcome this, is when I mutate a value I get the “text” back (or other value if thats not possible), I create an MD5 of that and store it using the account/integration & itemID as the key.
I store this to database with a ttl (so it automatically deletes after a period, one minute usually). Then on next trigger I check for for the existence of a hash, and if it exists i include the text of the column in the query to get values needed. Then I can check the MD5 of that and see if the value is different than what I just wrote or not, and if it is the same, I can return early with a no-op.
@Matias.Monday this no-op situation is one of the reasons I’d made the request elsewhere about a way to return no-op on a trigger and have it not consume an action since no action is ultimately performed.