Expand my Community achievements bar.

SOLVED

Workfront Fusion Watch Events Trigger queue duplicates

Avatar

Level 1

Hello, 

 

Fairly new to working on fusion but have been doing so now for around 6 months. I am currently working on a scenario that will create a new task based on the information that was on the just closed task with an updated future date. Essentially these are monthly and quarterly tasks to check on an automated project to assure they are working properly. My watch events trigger parameters are as follows:

 

Record type: Task
State: New state
Filters:
Name EQUAL Example Task Name
AND Status EQUAL CPL
AND connection user updates excluded
Record Origin: Updated Record Only

 

I just put a random example for task name but the names of these task are unique in that no other tasks in our system would have these names. What is happening is that when I test this in our sandbox environment and I complete the "Example Task Name" in Workfront it is pulling in two different events for the same exact task closure. This is resulting in my scenario running twice for the same closed task and creating a second duplicate task instead of just one task. Wondering if anyone has any suggestions to prevent this, or has experienced this before. Please let me know if more info is needed. 

 

Thanks, 

 

Gerald 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Level 6

I'm not sure if it would apply to your scenario, but we've got a scenario that is also triggered by task completion:

Record type: Task
State: New state
Filters:
Status Changed
AND Status EQUAL CPL
AND connection updates included
Record Origin: Updated Record Only

I haven't seen any duplicate executions.  Would re-creating your trigger with the 'Status Changed' added to the Filters statement work?

View solution in original post

4 Replies

Avatar

Community Advisor

Hi Gerald,

couple thoughts here.

1. I would definitely check with support to ensure what you're seeing is expected.

2. this maybe an instance of something I heard is called "race condition" and you cannot avoid it easily. My understanding of it is that despite user is making single update on a task, e.g. status change, multiple changes are being recorded by the system. Not sure if this is the best example, but when you "start work" you also "commit" to have this done, these are 2 separate events for the system:

Rafal_Bainie_0-1709645543373.png

I only took 1 action, but system activity tracks 2 events.

3. A way to avoid 2. would be to include data store in your scenario after watch event and store all data there. Include a delay in scenario, read the data from the data store looking specifically if there are duplicates, if there are, process only 1. 
Please note this may require using 2 separate scenarios.
hope this is helpful

Rafal

Avatar

Level 10


Hi @petersongw22,

 

Building on the second idea @Rafal_Bainie proposed, perhaps you could switch your event trigger to watch for the (one) Update that includes the phrase Workfront automatically injects.

 

Alternatively, if that seems too weak or fragile, perhaps you could use a batch job that looks for a condition that will be present after such uodates “settle”; frequently enough to catch all cases, but less often than a webhook to avoid the noise.

 

Regards,

Doug

Avatar

Correct answer by
Level 6

I'm not sure if it would apply to your scenario, but we've got a scenario that is also triggered by task completion:

Record type: Task
State: New state
Filters:
Status Changed
AND Status EQUAL CPL
AND connection updates included
Record Origin: Updated Record Only

I haven't seen any duplicate executions.  Would re-creating your trigger with the 'Status Changed' added to the Filters statement work?

Avatar

Level 1

Kristen, 

 

Thank you for this. It appears that adding that Status Changed filter has resolved this.