Exam AD0-E902 Topic 2 Question 21 Discussion
Actual exam question for Adobe's AD0-E902 exam
Question #: 21
Topic #: 2
Question #: 21
Topic #: 2
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?
Which action should a user take to keep this from happening?
Suggested Answer: B Vote an answer
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 aloop.
* 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.
References: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.
* 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 aloop.
* 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.
References: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.
by Lewis at Jul 07, 2026, 06:57 AM
0
0
0
10
Comments
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one. So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Report Comment
Commenting
You can sign-up / login (it's free).