My Fusion Scenario is producing double output

[ArthurChalamet]

We have been trying to set up Fusion scenarios to post an update each time a request is approved. Our approval process is as per below: 

1. Stage 1 approval process will be triggered by NEW status so that the approval will be triggered upon the request submission. 

2. If someone approves this on the first time, we want Fusion to be able to post an update in the request saying the request has been approved. 

3. If on the other hand they decide to reject it, the request status will be changed to 'Pending Requestor Input' and the requestor will be notified to amend the request. 

4. Once the requestor review the request, they are required to change the status of the request to 'Resubmitted' and this status will trigger the second stage of our approval workflows. 

Below is how our approval process is set up: 

We used the Fusion template (Convert Approved Issues to Project) to build two scenarios to automate this. One scenario is for NEW status and the other one is for the RESUBMITTED status. The scenario for NEW status works well with no issue. However when it comes to testing the second scenario, there were double output produced by the filter set causing double comments to be posted. 

The modules used: 

Watch field module set up: 

Filter set up. UKA is our key for RESUBMITTED custom status: 

Double bundle filtered by the filter: 

Could somehow guide me on how can we fix this? There should only be one bundle for each approved issue. However right now we're receiving two bundles for each approved issue. 

Any kind of help is greatly appreciated. Thank you!

Regards, 

Arthur

[_Manish_Singh]

Can you please create a new webhook and change the maximum number of returned events to 1? I'm not 100% sure if this is the right way to fix it, so I'm seeking for input from the community members.

[ArthurChalamet]

Hi Manish, 

The module we used for this scenario is Watch field module instead of Watch events / webhook. If I am to set up new module using webhook instead, may I know what kind of event filters should I use?

I am not able to find any thing that says oldTextVal

[_Manish_Singh]

I'm sorry for the confusion about the Watch Field module, I misread it. I'll look into the cause of the duplicate output.

[ArthurChalamet]

Thanks Manish! Truly appreciate it. 

[_Manish_Singh]

My guess is that the "Watch Field" module is causing the duplicates.

Assume your scenario runs every 15 mins. Let's say, in that 15 mins timeframe, the Issue object changes status twice. For example, 1) Pending Approval (:A) and 2) Resubmitted (or) Pending Requestor Input. That would create 2 outputs/bundles.

You might need to adjust the filter to filter for 1 bundle. Apologies that I couldn't provide the exact solution, but this is my guess. Let's see what the others think.

[ArthurChalamet]

I am not sure how to edit the filters. Hopefully more people will chip in. 

[RobertDy]

@ArthurChalamet 

I am experiencing double output from listeners. 

In my case, this is happening when only watching for new records. So surely this shouldn't trigger the listener twice.

I've raised 2 support tickets to try and get this solved, but they haven't yet confirmed the cause of this. I've had to include a check in my scenarios to check if the scenario has already run. Would love to see a fix for this.

[ChrisStephens]

It looks like there were two update events in Workfront that satisfied your filter criteria, so I would check the two triggering events, and see which one you actually wanted, and then adjust your filter accordingly.

If you can't do that, then I would put an aggregator right after the trigger, grouping by the ID, and process it that way. That way you will be guaranteed to only be processing one ID one time.

[KatherineLa]

Generally when I run into Fusion doing things more times than I expect, it's because in the underlying data there really ARE multiple things happening even though it seems like there should only be one. In this example, you see the action "issue was rejected, therefore status changed to XYZ" as a single action - but that's not what the data underneath that action actually does.

My screenshot here is from a Project Approval, where I set a single-use approval path to trigger when the status was changed to 'Testing', and then to 'Revert to Previous Status' upon rejection. Logically, that's two changes of status. Once to 'Testing' and then once back to 'Planning'. Logic and data however, don't always match.  

This is where a Journal Entry report will save your sanity. When I isolate my updates to that project, I see 3 status changes, not 2. The first at 10:37 was from Planning -> Testing/Awaiting Approval. But three minutes later when I said 'Reject', there were two status changes. The rejection /itself/ is also logged as a status change (AA to RJ), on top of the update of the official Status field from Testing back to Planning. 

That leads me to think that your filter criteria aren't really doing what you think they are, and I'd start looking at that angle.