Include info about trigger source in the custom action payload, to differentiate between user- and app-triggered events

Hi everyone.
I’ve (and other devs) asked a similar question several months ago.
I’ve proposed to add a couple of new fields to the payload sent to the custom action:

  • trigger_source_type: “user”, “app”, “date”, …;
  • trigger_source_id: user Id, app Id, …

@rachelatmonday Is it something in your to-do list?

1 Like

Although its propably a new topic I totally agree @rob, the triggering user (like in the screenshot) would also be very helpful in other scenarios :+1:

@rob you can get the triggering user in almost all integrations though already, with a user field and the source being “trigger output”.

Hey @rob,

Thanks for following up. I’m checking with the team to see the status of this.


Can you share a bit more why you need this?

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. :+1:

PS: Moved this to a new topic as it’s not super related to the previous one.

1 Like

Hey @codyfrisch
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.

Totally understand. So you want to be able to differentiate between blocks triggered by your own app vs a user. Thank you for explaining further!!!

1 Like