AD0-E902 Practice Questions

Step by Step Comprehensive Detailed Explanation:

Scenario Summary:

The source system provides a list of users, job roles, and departments.

The destination system requires a mapping of job roles to different departments.

Updates to this mapping are infrequent, and there is a concern for more security than a spreadsheet

offers.

Option Analysis:

A . Switch: A switch function in Workfront Fusion is used to make decisions based on specific

conditions but does not maintain persistent data like mappings over time. It is not suitable for storing

mappings that require infrequent updates.

B . Spreadsheet: Spreadsheets may be simple to use but are less secure and not ideal for integrating

with Workfront Fusion workflows due to their lack of direct integration features or control over

changes.

C . Data store: A data store in Workfront Fusion is specifically designed for storing persistent data,

such as mappings or reference tables. It is secure, easy to manage, and integrates seamlessly with

workflows, making it the best choice for this use case.

D . Table aggregator: A table aggregator is used for combining or processing data within a workflow

but is not suitable for storing persistent mappings outside of a running scenario.

Why Data Store is Appropriate:

Persistence: A data store is ideal for maintaining the job role and department mappings across

scenarios.

Security: It is managed within Workfront Fusion, offering better control and access restrictions

compared to a spreadsheet.

Ease of Integration: Data stores can be directly queried or updated in Fusion workflows, allowing

seamless handling of mappings.

Scalability: While updates are infrequent, the data store can handle changes easily and scale if the

volume of mappings increases.

Implementation in Workfront Fusion:

Create a data store for job roles and departments in Workfront Fusion.

Set up fields for Job Role and Department in the data store.

Use Workfront Fusion scenarios to retrieve and update mappings from this data store based on

requirements.

Reference:

This approach aligns with the Workfront Fusion documentation on data stores, which are designed

for secure and efficient storage of persistent data used across scenarios. See Workfront Fusion

resources for data store setup and use cases for further details.

B . Incomplete Executions Are Not Stored by Default:

By default, Workfront Fusion does not store incomplete executions unless this setting is explicitly

enabled in the scenario's settings.

This feature needs to be activated for troubleshooting and manually resolving incomplete executions

later.

D . Resolving Incomplete Executions:

When an incomplete execution is resumed, the scenario picks up from the point of failure and

processes the remaining steps with the data bundle that caused the error.

This ensures that the scenario completes its intended process without restarting entirely.

Why Not Other Options?

A . When incomplete executions are togged, a user must review the History tab to understand the

error and then manually run the entire scenario to resolve: This is incorrect because incomplete

executions do not require restarting the entire scenario; they continue from the point of failure.

C . Incomplete executions should be avoided because they only give visibility into better scenario

design: This statement is misleading. Incomplete executions are often inevitable and provide critical

insights into handling errors and improving scenarios.

Reference:

Adobe Workfront Fusion Documentation: Working with Incomplete Executions

Experience League Community: How to Enable and Manage Incomplete Executions in Fusion

Understanding the Requirement:

The user wants to enable resource sharing in Fusion, including connections, data stores, and keys.

Resource sharing is necessary to allow multiple scenarios or users to access shared resources

efficiently within the same Fusion environment.

Why Option B ("Create a new team") is Correct:

Teams in Fusion:

Teams are a feature in Adobe Workfront Fusion designed to group users together within an

organization.

By creating a team, you can enable shared access to resources such as API connections, data stores,

and authentication keys, streamlining collaboration and avoiding duplication.

Resource Sharing with Teams:

All members of the team can access shared resources (e.g., connections), allowing consistent and

collaborative scenario development and execution.

Example: If multiple users within a team need to use the same API connection, creating a team

allows the connection to be configured once and shared among all team members.

Why the Other Options are Incorrect:

Option A ("Create a new group"):

Groups in Fusion are used primarily for organizing scenarios or categorizing users but do not

inherently allow sharing of resources like connections or keys. Groups lack the resource-sharing

functionality of teams.

Option C ("Create a new organization"):

Organizations in Fusion represent the highest-level administrative entity. While creating an

organization allows resource sharing among all users within the organization, it is not the

recommended solution for managing resource sharing in smaller or more focused groups, such as

project teams.

Steps to Create a New Team and Share Resources:

Log in to Adobe Workfront Fusion.

Navigate to the Admin Panel or Team Management section.

Select Create a New Team and provide a name for the team.

Assign users to the team by adding their Fusion accounts.

Configure shared resources (e.g., connections, data stores, keys) to be accessible by the team.

Save the settings, and all team members will now have access to the shared resources.

How This Solves the Problem:

Creating a team ensures that all resources, such as connections, data stores, and keys, are accessible

to team members without requiring individual duplication or configuration. It simplifies

collaboration and promotes consistency across scenarios.

Reference and Supporting Documentation:

Adobe Workfront Fusion: Teams Overview

Workfront Community: Managing Teams and Resource Sharing

When encountering the error 429: Too many requests, which indicates the web service is being

overwhelmed by requests, the following actions can help:

A . Add a Sleep Module:

Adding a Sleep module introduces a delay between iterations, reducing the frequency of API calls.

By slowing down the rate of requests, you avoid hitting the rate limits of the web service, thus

reducing the chances of receiving a 429 error.

This approach is useful for managing high-volume iterations without overloading the external

service.

C . Add a Module to Test the Service for Errors:

Adding a module to test the service's response before making a call can help prevent the 429 error

by checking if the service is ready to handle requests.

This preemptive check allows the scenario to conditionally execute, ensuring that it doesn't

overwhelm the service and respects the API rate limits.

Why Not Other Options?

B . Use an Ignore Directive: Ignoring errors can be risky because it would cause the scenario to ignore

429 errors, possibly leading to failed API calls that are not addressed. Ignoring an error doesn’t solve

the issue of too many requests being sent to the service.

D . Use a Break Directive: The Break directive would stop the execution, which is counterproductive

when trying to resolve the issue by reducing the rate of requests. It would not address the root cause

of too many requests.

Reference:

Adobe Workfront Fusion Documentation: Handling API Rate Limiting with Sleep and Error Handling

Experience League Community: Managing Web Service Errors in High-Volume Iterations

Understanding the Scenario:

The scenario includes two modules:

Workfront Search Module: Fetches data (likely project details).

Tools Module: Manipulates and sets multiple variables.

What the Images Show:

Workfront Search Module (First Module):

The output indicates 29 bundles of project data were retrieved.

Each bundle contains fields such as ID, name, and plannedCompletionDate.

Tools Module (Second Module):

The data from the Workfront module is processed to set variables like Project Name and Project Due

Date.

Output includes transformed values, such as appending the approver’s name ("Joan Harris") to the

project name and updating the project due date.

Why Option C is Correct:

Delivery of 29 Bundles: The Workfront module retrieved 29 project bundles and passed them to the

Tools module.

Data Manipulation in Tools Module: The second module modified the data, such as appending "Joan

Harris" to the project name and updating the due date to a different value. This is evident from the

changes in the output of the Tools module compared to the input from the Workfront module.

Why the Other Options are Incorrect:

Option A:

Incorrect because the Workfront module retrieved 29 bundles, not just 1 bundle. Additionally, the

project name and planned completion date were manipulated in the second module, not the first.

Option B:

Incorrect because the retrieved data pertains to projects, not tasks.

Option D:

Incorrect because the input and output fields in the Tools module are not identical. The data was

clearly manipulated within the Tools module.

How This Scenario Operates:

The Workfront module fetches raw data, which is then processed in the Tools module. The processed

variables (e.g., modified project names and due dates) are prepared for further use in subsequent

scenario steps.

Reference and Supporting Documentation:

Adobe Workfront Fusion Documentation: Bundle Inspector

Workfront Community: Using Tools Module for Data Manipulation

The correct interpretation is that the first module delivered 29 bundles to the second module, where

data manipulations occurred to modify the project name and planned completion date.

Key Scenario Settings:

Adobe Workfront Fusion provides settings to control the execution of scenarios. These settings

impact how the scenario behaves when it runs, especially under conditions such as errors or long-

running processes.

Explanation of Correct Options:

Option A ("Number of consecutive errors"):

This setting determines the maximum number of consecutive errors allowed before the scenario

execution halts.

By adjusting this value, users can define how resilient the scenario is to temporary failures in

modules or external systems.

Option B ("Max number of cycles"):

This setting limits the maximum number of cycles (iterations) the scenario performs in a single run.

It prevents scenarios from running indefinitely or consuming excessive resources in cases of large

datasets.

Why the Other Options are Incorrect:

Option C ("Number of bundles per run"): This value is not adjustable in the scenario settings. Instead,

the system dynamically determines how many bundles (data packets) are processed per cycle.

Option D ("Number of consecutive runs"): Workfront Fusion does not have a setting for the number

of consecutive runs. Scenarios are executed based on schedules, triggers, or manual execution.

Steps to Adjust Scenario Settings:

Open the scenario in Adobe Workfront Fusion.

Click the gear icon in the top-right corner to access Scenario Settings.

Locate and adjust the following fields:

Number of consecutive errors: Set a value based on acceptable failure tolerance.

Max number of cycles: Specify the maximum number of iterations allowed.

Save and activate the scenario.

Reference and Supporting Documentation:

Adobe Workfront Fusion Official Documentation: Scenario Settings

Workfront Community: Best Practices for Scenario Optimization

Workfront's training on scenario testing emphasizes the importance of a well-structured test plan to

ensure scenario reliability and accuracy. The three essential elements include:

B . Description of Expected Behavior:

This provides clarity on what the scenario is supposed to achieve when executed successfully.

It serves as a benchmark for evaluating the outcome of test executions.

C . Specific Event/Trigger per Scenario:

Identifying and testing specific triggers ensures that the scenario starts under the correct conditions.

This is crucial for verifying the proper configuration of the scenario’s start point.

D . Description of Testing Steps:

Outlining step-by-step instructions for the testing process ensures that all aspects of the scenario are

tested systematically.

It helps identify potential bottlenecks or areas for improvement in the scenario’s configuration.

Why Not Other Options?

A . Roadmap requirements: This pertains to project planning and is not directly relevant to scenario

testing.

E. Executive sponsor expectations: While valuable for overall project alignment, it is not an essential

component of a technical test plan.

Reference:

Workfront Training Materials: Best Practices for Scenario Testing

Experience League Documentation: How to Design and Execute a Test Plan for Workfront Fusion

Scenarios

Understanding the Expression:

The provided expression uses the ifempty function:

ifempty(2.data:types[]; "No Type")

Structure of the Expression:

The first parameter, 2.data:types[], is an array being checked for content.

The second parameter, "No Type", is the fallback value returned if the array is empty or undefined.

Purpose of ifempty: This function checks if the given value is empty or undefined. If the value is not

empty, it returns the value. If the value is empty, it returns the fallback text ("No Type").

Expected Module Outputs:

A . Non-empty array:

If 2.data:types[] is a non-empty array, the function returns the array as-is.

C . Text value 'No Type':

If 2.data:types[] is empty or undefined, the function returns the fallback text value "No Type".

Why the Other Options are Incorrect:

Option B ("An empty field"):

The ifempty function does not return an empty field. If the value is empty, it substitutes it with the

fallback text ("No Type").

Option D ("Collections comma separated"):

The function operates on arrays, but it does not format the output as comma-separated collections.

The raw array is returned if non-empty.

Key Use Cases:

This type of function is frequently used in Workfront Fusion to handle situations where data might be

missing or incomplete, ensuring scenarios continue to run smoothly without errors caused by

undefined or empty fields.

Example Outputs:

If 2.data:types[] = ["Type1", "Type2"]: The function returns ["Type1", "Type2"].

If 2.data:types[] = [] or undefined: The function returns "No Type".

Reference and Supporting Documentation:

Adobe Workfront Fusion Functions Reference

Workfront Community: Handling Empty Fields with ifempty

Understanding HTTP Response Codes:

HTTP response codes are standardized codes that indicate the result of a request made to a server:

2xx (Success): Indicates that the request was successfully received, understood, and processed by the

server.

200 OK: Specifically means that the request was successful, and the response contains the requested

data or confirms the operation's success.

Response Code for Creating a Record:

When using an HTTP module in Fusion to create a new record, a response code of 200 confirms that

the request to the server was successfully processed and the record creation was successful.

Why Not Other Options?

A . GREEN: This is not a valid HTTP response code. It might represent a status in some systems but is

unrelated to HTTP standards.

C . 402: This code indicates a payment required error, meaning the request cannot be fulfilled until

payment is made.

D . 500: This is a server-side error, indicating that something went wrong on the server during

processing.

Reference:

HTTP Status Code Documentation: 200 Success Response

Adobe Workfront Fusion Documentation: HTTP Module and Response Codes

Thank you for your visit.

Step by Step Comprehensive Detailed Explanation:

Problem Summary:

The Fusion scenario updates the project condition multiple times, once for each high-priority issue.

The desired behavior is to update the project condition only once, based on the overall condition of

all associated issues.

Option Analysis:

A . Change the issue search module to result set of First Matching:

This would limit the search to only the first issue. However, this does not account for all issues on the

project, leading to incomplete logic for setting the project condition.

B . Add an Ignore error directive as an error handler route for the update module:

Ignoring errors does not prevent multiple updates; it only suppresses errors in the workflow.

C . Create a separate scenario to update the overall project condition:

Correct. By separating the project update logic into a different scenario, the developer can ensure

the condition is updated only once after analyzing all issues. The project condition is calculated

holistically, based on the state of all high-priority issues.

D . Apply the Run Once flow control function:

"Run Once" controls execution at the scenario level, not within a module's iteration. It cannot

prevent multiple updates in this context.

Why Separate Scenario is Best:

Simplifies Logic: A separate scenario can be designed to run after all issues have been checked,

ensuring only one update per project.

Avoids Redundancy: Prevents unnecessary API calls to update the same project multiple times.

Improves Performance: Reduces the number of operations and bundles processed in the main

scenario.

Implementation:

Create a separate scenario triggered after the issue-checking scenario completes.

Use aggregate data (e.g., a data store or intermediate processing) to evaluate the overall project

condition before performing a single update.