"Watch Events" module getting triggered twice

[_Manish_Singh]

I have a situation where a scenario is getting triggered twice whenever the "assignments" field is updated. The first module is "Watch Events" with record type "Assignment". Every time I add 1 or more assignment, the scenario triggers twice for each assignment.

I've noticed that the "Exclude events made by this connection" checkbox is not present for the "Assignment" record type. Could someone verify if this is the cause of the issue? or a share potential solution please?

[stuartcairns]

Hi Manish, it could be that and I recommend you tick that box to prevent self-generated events.  However, it could also be running multiple times if you have more than one assignee.  Check the number of bundles coming out of the upstream modules. All the best, Stuart

[_Manish_Singh]

Hi @stuartcairns - Unfortunately, the checkbox is missing for record type "Assignments" by default.

You're right, it runs multiples times. I'm expecting it to run 2 times when I add 2 assignees. However, it runs 4 times (2x) in my case (don't know why).

[stuartcairns]

Hi Manish, it'll be running twice for each of your two assignees.  Try putting an array aggregator on, linking back to the object, presumably a task, the assignees are assigned to, so you have a single output bundle.

Stuart  

[D____D]

I am running into a similar issue here and like you suggested, I actually have an aggregator and an array but in my case, I am ending up with the Project Create Module running twice. Frankly, this is mess because folks are ending up with with two projects.  Perhaps there's a simpler way to do this that we just don't understand.  

In my case, I'm looking at an issue's list that leverages custom form with a multi-select field.  

That field is then put into an array via an aggregator to create one or more project(s).  

The aggression and array portions works fine, but what baffles me is that in some cases, the "value" of the array runs twice - that just should not be the case in my humble opinion (no errors, just looks normal, even the logs show that each execution running at the exact same exact time down to the second). 

[SebastianUndu · Accepted solution]

Hi, you can try adding this filter after the watch event

Just compare that the oldState is not equal to the newState

[D____D]

Can you explain what this does exactly? I can tell from reading it, but can you share your intent here? Thank you kindly.

[SebastianUndu]

Yes, I have something like a button (yes/no) that is the trigger of this scenario at the project level. As it's a Watch event scenario, each time that someone touch anything in the project, it retriggered, so I use that filter to only run it if it was a change of the button. 

I used to have a similar issue in Saleforce, so we added timestamps or system buttons and some rules around them, like it can only run 1 minute after the timestamp, but you can get a similar approach using the old versus new status.

For example, you can use:
Old Status | lastUpdateDate March 14, 2024 12:05 PM

New Status | lastUpdateDate March 18, 2024 10:23 AM

Hope it helps

[D____D]

That makes sense to me. I actually opened a ticket with Adobe at the same time I submitted this teams requests, and it seems like they offered the same solution. Not sure who is the check or egg here but I'm grateful. Thank you.

[_Manish_Singh]

Hi @SebastianUndu - I was checking the old state and the new state after your suggestion and this is what I found:

1) The first trigger always returned an empty old state (see below):

2) The second trigger always returned new state = old state (see below):

Any idea what is happening here? I have added 1 assignment to my task, and it triggered the scenario twice.

[D____D]

This seems like something can pre-pid so avoid. We can't be the only ones going through this given how forms work and how updates work in conjunction with Fusion. I had long suspected that the only way that this was probably happening was because of some kind of "other" update that was being registered - I had never considered it would be the state values.  Nice catch guys.

[Doug_Den_Hoed__AtAppStore]

Hi @_Manish_Singh,

I happen to re-read this popular post last week, and at the very end (noting it takes hitting “Load more” twice to get there), rediscovered one reason that can cause two updates to fire in quick succession.

It’s worth a full read in context, so I won’t repeat it all, but in short: if you have custom calculated parameters in play, that can do it….

Regards,

Doug

[D____D]

Excellent - thank you.