New Year Sale 2026! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions

Adobe AD0-E902 Exam - Topic 3 Question 2 Discussion

Actual exam question for Adobe's AD0-E902 exam
Question #: 2
Topic #: 3
[All AD0-E902 Questions]

A Fusion scenario is triggered by a project status update. The scenario then updates the status, causing repeated execution of the scenario.

Which action should a user take to keep this from happening?

Show Suggested Answer Hide Answer
Suggested Answer: B

Step by Step Comprehensive Detailed Explanation:

Understanding the Problem:

The scenario is triggered by a project status update.

After the scenario runs, it updates the project status again, which re-triggers the scenario, creating a loop.

The goal is to prevent the scenario from re-triggering itself.

Option Analysis:

A . When using instant triggers, finish the scenario with the Break directive to prevent the record from being updated again:

Incorrect. The Break directive is not used to prevent updates; it is used to stop further iterations of a scenario. It does not address the root cause of the loop, which is the re-triggering by updated records.

B . Create a filter after the instant trigger that only passes records that have not been updated by Fusion:

Correct. Adding a filter ensures that only records not recently updated by Fusion are processed. This prevents Fusion from re-triggering itself on the same record.

For example, you could use a condition to check if the Last Updated By field does not equal the Fusion user or if the Last Update Date is older than a certain threshold.

C . Schedule the instant trigger to only run at intervals to prevent Fusion from thinking the record has been updated after each run:

Incorrect. Instant triggers are event-driven, and their purpose is to respond to changes immediately. Scheduling them would negate the benefit of instant triggers and does not solve the root problem.

Why Filtering Records is Best:

Targeted Control: A filter after the trigger ensures only relevant updates (e.g., those not caused by Fusion) are processed.

Prevents Loops: By excluding records updated by Fusion, the scenario avoids re-triggering itself.

Maintains Performance: Filtering prevents unnecessary processing of irrelevant records, improving efficiency.

How to Implement:

After the instant trigger module, add a filter module.

Configure the filter to check the Last Updated By field or a custom flag indicating if the update was performed by Fusion.

Example: Last Updated By Fusion User or Update Flag True.

If a custom flag is used, ensure the flag is set when Fusion updates the record.

Alternative Solutions:

Add a custom field (e.g., 'Updated by Fusion') that Fusion sets when it updates a record. This can also be used in the filter condition.

Reference: This approach aligns with Fusion best practices for preventing infinite loops caused by scenarios re-triggering themselves. Filtering ensures the scenario runs only when necessary, avoiding redundant processing and maintaining performance.


Contribute your Thoughts:

0/2000 characters
Frank
3 months ago
I’m not sure about that, what if the filter misses some updates?
upvoted 0 times
...
Avery
3 months ago
Filters are definitely the way to go, keeps things clean!
upvoted 0 times
...
Lonny
3 months ago
Wait, can you really schedule instant triggers? Sounds odd.
upvoted 0 times
...
Lynelle
4 months ago
I disagree, option A seems more straightforward.
upvoted 0 times
...
Asha
4 months ago
I think option B is the best choice here.
upvoted 0 times
...
Tatum
4 months ago
I’m leaning towards option A, but I’m a bit uncertain about how the Break directive actually works in this context.
upvoted 0 times
...
Fabiola
4 months ago
I feel like scheduling the trigger might not be the best solution. It seems like it could still lead to confusion about the record's status.
upvoted 0 times
...
Caprice
4 months ago
I think option B sounds familiar. We practiced a similar question where filtering records helped avoid repeated updates.
upvoted 0 times
...
Alita
5 months ago
I remember we discussed how instant triggers can cause loops if not handled properly, but I'm not sure if the Break directive is the right choice here.
upvoted 0 times
...
Doyle
5 months ago
I'm leaning towards Option A. The Break directive feels like the cleanest way to stop the repeated execution of the scenario after the status update. It's a straightforward solution to the problem.
upvoted 0 times
...
Avery
5 months ago
Scheduling the trigger to run at intervals could work, but I'm not sure that would fully prevent the repeated execution. The scenario is triggered by a status update, so it seems like we need a more targeted solution to stop that loop.
upvoted 0 times
...
Misty
5 months ago
Hmm, I'm a bit confused. Wouldn't a filter after the trigger be a better way to only pass through records that haven't been updated by Fusion? That seems more direct than using the Break directive.
upvoted 0 times
...
Lynna
5 months ago
I think the key here is to prevent the record from being updated again after the scenario runs. Option A with the Break directive sounds like the best way to do that.
upvoted 0 times
...
Reyes
1 year ago
I'm not sure, but option B) Create a filter after the instant trigger that only passes records that have not been updated by Fusion also sounds like a good solution.
upvoted 0 times
...
Lavonna
1 year ago
I agree with Ciara. That seems like the best way to prevent the scenario from executing repeatedly.
upvoted 0 times
...
Britt
1 year ago
I'll have to go with option A. Breaking the scenario seems like the most straightforward way to stop the madness. It's not like I have all day to keep rerunning this thing, you know?
upvoted 0 times
Margurite
12 months ago
Let's go with option A then, to prevent the record from being updated again.
upvoted 0 times
...
Orville
12 months ago
Definitely, we don't want the scenario to keep executing repeatedly.
upvoted 0 times
...
Narcisa
12 months ago
I agree, finishing the scenario with the Break directive seems like the most efficient solution.
upvoted 0 times
...
Lisandra
1 year ago
Option A sounds like the best choice to me.
upvoted 0 times
...
...
Stephane
1 year ago
I'm leaning towards option C. Scheduling the trigger to run at intervals could be a neat way to avoid the repeat executions.
upvoted 0 times
...
Alishia
1 year ago
Hmm, option B sounds like a good idea. Filtering out the already updated records seems like a simple solution.
upvoted 0 times
...
Ciara
1 year ago
I think the answer is A) When using instant triggers, finish the scenario with the Break directive to prevent the record from being updated again.
upvoted 0 times
...
Lashaun
1 year ago
I think option A is the way to go. The Break directive should prevent the scenario from running again and again.
upvoted 0 times
Vashti
1 year ago
I think option C could also work, by scheduling the trigger to run at intervals.
upvoted 0 times
...
Shala
1 year ago
I agree, using the Break directive should stop the scenario from repeating.
upvoted 0 times
...
...

Save Cancel