Free AD0-E903 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

The Adobe Workfront scheduling engine calculates the Planned Start Date based on multiple factors, including task dependencies, constraints, and resource availability. A primary reason for a discrepancy between an expected start date (derived from predecessors) and the actual Planned Start Date is the schedule of the primary assignee. If the primary task owner has approved time off logged in their Workfront calendar for Tuesday, Wednesday, and Thursday, the system will automatically push the task's Planned Start Date to Friday, their next available working day.

B. A team review is a manual business process; it does not explain why the Workfront system would automatically calculate a different Planned Start Date.

C. This option describes a result, not a cause. The Planned Start Date determines when the duration and planned hours begin, not the other way around.

1. Adobe Workfront Documentation - Set the project schedule: "Workfront uses the schedule of the Primary Assignee of a task to determine the Planned Dates of the task." This confirms that the primary user's schedule

which includes time off

is the key factor. (Source: Adobe Experience League

Set the project schedule

Section: "How Workfront uses user and project schedules to generate a project timeline").

2. Adobe Workfront Documentation - Overview of time off in Workfront: "When a user has approved time off

Workfront considers them unavailable for work on tasks and issues. If a task or issue is assigned to the user during their time off

the Planned Dates of the work item are adjusted to begin on the next available work day." (Source: Adobe Experience League

Overview of time off in Workfront

Section: "How time off affects user availability and task dates").

3. Adobe Workfront Documentation - Planned Start Date overview: "The Planned Start Date is the date when Workfront determines work on a task can begin. This calculation is based on... the schedule of the primary assignee." This explicitly links the Planned Start Date calculation to the assignee's schedule. (Source: Adobe Experience League

Planned Start Date overview for tasks).

The core issue is the ambiguity of using the single "Planning" status for two distinct project states: waiting for team capacity (backlog) and actively being prepared for execution. Creating a custom "Backlog" status introduces a clear, sequential stage in the project lifecycle. This allows projects created from templates to be placed in the "Backlog" status initially. Once the team has capacity and begins active preparation, the status can be changed to "Planning." This provides an unambiguous, system-driven way for the team to differentiate between the two states, directly resolving the stated confusion.

A. Load the project template once the team has bandwidth to start on the project.

This approach avoids creating a backlog, which contradicts the requirement that projects are created for the year and wait until the team has capacity.

B. Create projects but leave the roles in place without assigning users.

Staffing status (assigned vs. unassigned roles) is separate from the project's lifecycle status. This does not resolve the confusion over whether a project is in a backlog or being actively planned.

1. Adobe Experience League Documentation - Create or edit a status: This document explains the process and purpose of creating custom statuses. It states

"You can create custom statuses to match the workflows in your organization." Creating a "Backlog" status is a direct application of this functionality to define a specific workflow step.

Source: Adobe Workfront Documentation

"Create or edit a status

" Section: "Create a custom status."

2. Adobe Experience League Documentation - System project statuses: This document defines the default "Planning" status. Its intended use is for when "the project is being planned and prepared." Using it for a pre-planning backlog overloads its meaning

justifying the need for a separate

custom status for the backlog phase.

Source: Adobe Workfront Documentation

"System project statuses

" Section: "Planning."

3. Adobe Experience League Documentation - Customize unlocked system statuses: This guide details how administrators can tailor statuses to fit their organization's needs. It reinforces the principle that Workfront's status system is designed to be flexible and adapted to specific processes

such as implementing a backlog stage before the standard planning stage.

Source: Adobe Workfront Documentation

"Customize unlocked system statuses."

The Planned Completion Date is the date a task is scheduled to be completed within the project plan. When an assignee needs to adjust the timeline for a task that is not yet finished, they must update this field. This date is the primary driver for the project schedule, affecting dependencies and the overall project timeline displayed on tools like the Gantt chart. It represents the official, scheduled end date for the work item.

A. Actual Completion Date: This date is automatically recorded by the system when the task's status is changed to a 'Complete' equivelant. It is a historical record, not a future plan.

B. Commit Date: This is a date manually set by a user to indicate a personal promise to complete the work. It operates independently of the project's calculated schedule.

D. Projected Start Date: This date is a system-calculated forecast of when a task might begin, based on predecessor progress and other factors. It is read-only and cannot be updated by an assignee.

1. Adobe Workfront Documentation

"Overview of the Planned Completion Date for tasks." This document states

"The Planned Completion Date is the date when the task is scheduled to be complete... You can manually modify the Planned Completion Date of a task when the Task Constraint is different from As Soon As Possible and As Late As Possible." This confirms it is the updatable

scheduled completion date.

2. Adobe Workfront Documentation

"Overview of the Actual Completion Date." This source clarifies

"The Actual Completion Date is the date and time when a work item was completed. Adobe Workfront automatically populates this field when the status of the work item changes to a status that equates with Complete." This confirms it is an automatically populated

historical field.

3. Adobe Workfront Documentation

"Update the Commit Date for a task." This article defines the Commit Date: "The Commit Date is the date you promise to complete a work item." This distinguishes it from the formal Planned Date.

4. Adobe Workfront Documentation

"Projected Dates overview." This document explains

"Projected Dates are Adobe Workfront’s best guess as to when a task... will be completed... You cannot manually edit the Projected Dates of tasks." This confirms the field is read-only and a system forecast.

In Adobe Workfront, when multiple users are assigned to a single task, the system designates a "Primary Assignee." This designation is determined by the order of assignment. The very first user assigned to the task automatically becomes the Primary Assignee. This user is typically considered the main point of contact for the task, responsible for coordinating the effort with other assignees and for marking the task as "Done" upon completion. The primary assignee can be changed manually after the initial assignments have been made.

A. By the user on a task that has a primary job role.

A user's primary job role is a profile-level attribute used for resource management and capacity planning, not for determining the primary assignee on a specific task.

B. By the Home Team assigned to a task.

A user's Home Team is an organizational attribute. While a task can be assigned to a team, this does not determine which individual user becomes the primary assignee.

1. Adobe Workfront Documentation - Assign tasks: In the section "Assign multiple users to a task

" the documentation explicitly states

"The first user you assign to the task becomes the task Primary Assignee. The Primary Assignee is responsible for coordinating the work on the task and for marking the task Done."

Source: Adobe Experience League

Workfront Documentation. (Accessed under the path: Workfront > Get Started > Adopt & govern Workfront > Create & manage work > Manage tasks > Assign tasks).

2. Adobe Workfront Documentation - Edit task assignments: This document details how to modify assignments

including changing the primary assignee

which reinforces that the initial primary status is set by assignment order. It states

"You can change the primary assignee for a task or issue that has multiple assignees."

Source: Adobe Experience League

Workfront Documentation. (Accessed under the path: Workfront > Get Started > Adopt & govern Workfront > Create & manage work > Manage tasks > Edit task assignments).

The core requirement is to reduce a task's duration by adding more resources while keeping the total amount of work (40 hours) constant. The Effort Driven Duration Type is specifically designed for this scenario. When a task is set to Effort Driven, the total Planned Hours (effort) are treated as a fixed value. As more resources (users) are assigned to the task, Adobe Workfront automatically recalculates and shortens the task's duration by distributing the fixed effort among the assignees. This allows the 40 hours of work to be completed in less time by four people.

B. Change the Task Duration Type to Calculated Work: This is incorrect because the Calculated Work type recalculates the total work based on the duration and the number of resources. It would increase the planned hours, not shorten the duration.

C. Change the Task Constraint to Fixed Dates: This only forces the task to start and end on specific dates. It does not change the underlying calculation of how work is distributed among resources to meet that deadline.

D. Change the Task Constraint to As Soon As Possible: This is a scheduling constraint that places the task as early as possible based on dependencies. It does not influence the relationship between duration, work, and resource allocation.

1. Adobe Experience League

Workfront Documentation. "Overview of Task Duration and Duration Type." In the section "The Effort Driven Duration Type

" it states: "When you select the Effort Driven Duration Type

Workfront recalculates the duration of the task when you assign more resources to it. The Planned Hours on the task are distributed equally among the new resources and the duration is shortened." This directly supports the correct answer.

2. Adobe Experience League

Workfront Documentation. "Overview of Task Duration and Duration Type." The section "The Calculated Work Duration Type" explains: "When you select the Calculated Work Duration Type

Workfront recalculates the Planned Hours (Work) for the task using the following formula: Planned Hours = Task Duration number of resources assigned percent allocation of resources." This confirms why option B is incorrect for this scenario.

3. Adobe Experience League

Workfront Documentation. "Task Constraint overview." This document details the function of various task constraints

including "Fixed Dates" and "As Soon As Possible

" clarifying that their purpose is to define scheduling boundaries

not to manage the work-duration-resource calculation

which makes options C and D incorrect.

In Adobe Workfront, associating a task with a milestone step can be done directly from the project's task list. The most common methods are using in-line editing by adding the "Milestone" column to the view, which allows for quick, single-task updates. For efficiency when multiple tasks need to be linked to the same milestone step, the bulk-editing functionality is used. A user can select several tasks from the list and assign them to a milestone step in a single action.

B. The Milestone View is a visualization tool used to track the progress of the milestone path; it does not provide functionality to associate tasks with milestone steps.

D. The "Settings" section within a task's details page contains configurations like task constraints and duration type, not the field for associating the task to a milestone step.

1. Adobe Workfront Documentation - Associate tasks with milestones: This document explicitly details the two primary methods.

For In-line Editing (A): Under the section "Associate a task with a milestone in a list

" it states

"You can associate a task with a milestone when editing it in a list of tasks... Add the Milestone column to your task view. Click the Milestone column for the task you want to associate with a milestone

then start typing the name of the milestone."

For Bulk-Editing (C): Under the same section

it describes the bulk edit process: "Select multiple tasks in a task list... Click the Edit icon... In the Edit Tasks box that displays

scroll to the Milestone field and start typing the name of the milestone."

2. Adobe Workfront Documentation - Edit tasks: This document clarifies the different editing areas for a task. The "Milestone" field is located in the "Task Details" section of the Edit Task dialog box

not in the "Settings" section

confirming why option D is incorrect.

3. Adobe Workfront Documentation - Milestone view: This source confirms the purpose of the Milestone View. It states

"The Milestone view provides a simple

easy-to-read

visual representation of the milestone path on your project

" confirming it is for visualization

not for editing task associations

which makes option B incorrect.

This configuration correctly separates the work effort from the time span. The Task Constraint of "Must Start On" locks the start date to September 23. Planned Hours represents the total amount of work or effort required, which is 10 hours. Duration defines the total working timeframe from the task's start to its completion, which is 2 weeks. This allows the 10 hours of work to be distributed across the 2-week period as needed, fulfilling all requirements of the scenario.

A. This option incorrectly assigns the time span (2 weeks) to "Planned Time" and the work effort (10 hours) to "Duration," which reverses their intended meanings in Adobe Workfront.

C. This option uses incorrect terminology. "Issue Duration" is a field specific to Issues, not Tasks. While a "Start Date" can be set, a "Must Start On" constraint is the correct mechanism to enforce it.

1. Adobe Workfront Documentation

"Overview of Task Constraints": This document explains that the "Must Start On" (MSO) constraint forces a task to begin on the specified date. This directly supports the use of this constraint for the September 23 start requirement. (See section: "Must Start On").

2. Adobe Workfront Documentation

"Overview of Planned Hours": This source defines Planned Hours as "the amount of time you estimate it will take to complete a work item." This confirms that the 10 hours of work effort should be entered in the Planned Hours field. (See section: "How Workfront uses Planned Hours").

3. Adobe Workfront Documentation

"Duration and Duration Type overview": This article clarifies the distinction between Duration and Planned Hours. It states

"Duration is the amount of time (in business days) that it will take for a work item to be completed

from the start date to the completion date." This validates setting the Duration to 2 weeks to represent the total time span. (See section: "Understanding the difference between Duration and Planned Hours").

In the Adobe Workfront object hierarchy, a Portfolio is a high-level container designed to group and manage a collection of related projects and programs. This structure is fundamental for strategic planning and oversight. Therefore, a Portfolio acts as a parent object, with projects and programs being its direct child objects. While a project is a parent to tasks, the portfolio's primary and defining function is to serve as a parent container for other major work objects like projects.

A. Issue: An Issue represents an unplanned work item and is typically a child object linked to a project or a task. It does not function as a parent object.

B. Project: While a project is a parent object to tasks, it is also a child object within a portfolio or program. The portfolio is a higher-level strategic container.

1. Adobe Experience League - Get started with Adobe Workfront portfolios: This document states

"A portfolio is a collection of projects

and optionally

programs." This explicitly defines the parent-child relationship where the Portfolio is the parent. (See the "Overview of Adobe Workfront portfolios" section).

2. Adobe Experience League - Adobe Workfront object hierarchy: This guide visually and textually represents the object hierarchy

placing Portfolios at a higher level than Projects. It clarifies that Portfolios contain Programs and Projects

which in turn contain Tasks. (See the "Object hierarchy diagram" and "Object relationships" sections).

3. Adobe Experience League - Projects overview: This source describes a project as a collection of tasks. It notes

"A project is a planned set of interrelated tasks..." This confirms a project can be a parent

but the documentation on portfolios establishes the Portfolio as the higher-level parent container for projects themselves. (See the introductory paragraph).

In Adobe Workfront, the project status indicates the phase of the project lifecycle. When a project's status is set to 'In Progress' (or the system equivalent, 'Current'), it signifies that active work has commenced. By default, the system assumes the project is proceeding according to plan at this stage. Therefore, it automatically sets the project's 'Condition' to 'On Target'. This condition remains until it is manually updated by a project manager or automatically changed based on progress and variance calculations.

B. Idea: The 'Idea' status is used for project requests before they are approved and converted into projects. Its default condition is 'Requested'.

C. New: The 'New' status typically indicates that a project has been created or approved but work has not yet started. Its default condition is 'Requested'.

1. Adobe Experience League - Overview of system project statuses: This document outlines the default statuses in Workfront. It specifies that the status 'Current' (the system key for statuses like 'In Progress') equates to the condition 'On Target'. It also shows that 'Idea' and 'Planning' (similar to 'New') equate to the condition 'Requested'.

Reference: Adobe Workfront Documentation

"Overview of system project statuses

" Section: "System project statuses."

2. Adobe Experience League - Create and edit statuses: This guide explains how administrators can configure statuses

including setting the default condition associated with each status. It confirms the system's default behavior where an active status like 'In Progress' is mapped to 'On Target'.

Reference: Adobe Workfront Documentation

"Create and edit statuses

" Section: "Create or edit a status."

The Finance section at the project level in Adobe Workfront is specifically designed to track and display financial metrics. It provides a consolidated view of budgeted versus actual costs, including labor costs which are derived from hours. This section calculates and displays variances between the planned budget (Budgeted Hours/Cost) and the actual effort (Actual Hours/Cost), allowing a project manager to see financial performance and discrepancies for specific timeframes, such as the current week.

A. Utilization section: This section focuses on resource capacity and allocation by comparing planned hours against user availability, not on the financial variance between budgeted and actual hours.

B. Hours tab: This tab is primarily for logging and viewing the raw data of actual hours spent on project tasks. It does not inherently display calculated budget variances.

1. Adobe Workfront Documentation

"Manage project finances": The Finance sub-tab on a project is the designated area to "view financial information for the project. You can view information about budgeted and actual labor costs

as well as planned and actual expenses and revenues for a project." This section explicitly contains fields like "Budgeted Labor Cost

" "Actual Labor Cost

" and "Labor Cost Variance

" which directly address the user's need. (Reference: Adobe Experience League

Manage project finances

Section: "The Finance sub-tab").

2. Adobe Workfront Documentation

"View logged hours in a project": This document clarifies that the Hours tab is used to "view all the hours logged for the project" and "add new hours for the project." It serves as a repository for actual time entries

which are then used in calculations shown elsewhere

like the Finance section. (Reference: Adobe Experience League

View logged hours in a project

Section: "Access requirements").

3. Adobe Workfront Documentation

"View resource utilization information": This source explains that utilization information is used to "compare the number of planned hours for a user with their available hours during a specific time." This confirms its purpose is resource capacity management

not financial variance analysis. (Reference: Adobe Experience League

View resource utilization information

Overview section).

A project report is the most appropriate tool for viewing detailed information about individual projects. Grouping this report by portfolio organizes the projects according to strategic initiatives, which is ideal for an executive audience. The columns for project condition (health), project priority (importance), and custom data for business goals directly address the executive team's need for visibility into health, importance, and strategic alignment. This combination provides a comprehensive, strategically-oriented overview for data-driven decision-making, precisely matching the request.

B: Grouping by team provides an operational view, which is less relevant for strategic executive decisions compared to grouping by portfolio.

C: This option is incorrect because it provides program health, whereas the executive team specifically requested visibility into the health of individual active projects.

1. Adobe Workfront Documentation

"Create a project report": This guide details how to build reports using the Project object. It confirms that fields like Condition

Priority

and custom data fields can be added as columns

and that reports can be grouped by Portfolio. This supports using a project report to meet the specified requirements. (See section: "Build a project report").

2. Adobe Workfront Documentation

"Portfolios in Adobe Workfront": This document explains that portfolios are used to manage a collection of projects that align with the strategic objectives of an organization. Grouping a project report by portfolio

therefore

directly supports the need for visibility into strategic alignment. (See section: "The portfolio management process").

3. Adobe Workfront Documentation

"Overview of project Condition": This article defines Project Condition as the "overall health of the project." This directly links the project condition field to the executive's requirement for visibility into project "health." (See section: "How project Condition is calculated").

In Adobe Workfront, a task's 'Percent Complete' and its 'Status' are distinct fields. A project cannot be set to 'Complete' if any of its tasks have a status that does not equate to a complete state (e.g., 'In Progress', 'New'), even if those tasks show 100% in the 'Percent Complete' field. The system error occurs because the project's completion is gated by the task status, not just the percentage. The Project Owner must identify tasks that are 100% complete but still have an active status and update their status to 'Complete' or an equivalent. Filtering the task list for incomplete tasks is the correct procedure to locate them.

A. While an incomplete approval can prevent a task's status from being updated, the direct cause of the project-level error is the task's status itself, not the pending approval.

B. This option incorrectly focuses on project issues. The question specifically asks how to determine which tasks are incomplete, not which issues are open.

1. Adobe Workfront Documentation

"Update the status of a project": This document outlines the prerequisites for changing a project's status. It explicitly states

"You cannot mark a project Complete if there are incomplete tasks or open issues on the project." This directly supports the error message received by the user and the core problem. (Source: Adobe Experience League

Workfront Documentation

Projects section).

2. Adobe Workfront Documentation

"Overview of Task Status": This article explains the difference between system statuses. It clarifies that statuses like 'New' and 'In Progress' represent incomplete work

whereas the 'Complete' status signifies that the task is finished. This distinction is central to the question

as a task at 100% can still have an 'In Progress' status. (Source: Adobe Experience League

Workfront Documentation

Tasks section).

3. Adobe Workfront Documentation

"Edit tasks": In the section detailing task fields

the documentation describes 'Percent Complete' and 'Status' as separate

editable fields. It notes that setting a task's status to 'Complete' automatically sets the 'Percent Complete' to 100%. However

the reverse is not a default behavior; setting 'Percent Complete' to 100% does not automatically change the status to 'Complete'

which is the root cause of the scenario in the question. (Source: Adobe Experience League

Workfront Documentation

Tasks section).

This approach correctly addresses all requirements. Creating a Project report is the correct starting point. Adding the 'Actual Cost' column and sorting it in descending order fulfills the request to see the most expensive projects first. Most importantly, adding a prompt for 'Portfolio Name' from the Report Settings is the specific function that allows a user to select a single, specific portfolio each time the report is run. This makes the report reusable for any portfolio as requested by the executive.

B. Grouping and summarizing by SUM would show the total cost for all portfolios, not the individual project costs within a single, selected portfolio as requested.

C. Grouping by Portfolio Name displays all portfolios in the same report, which does not meet the requirement to select and view a single, specific portfolio.

1. Adobe Experience League Documentation - Create a custom report: This document outlines the initial steps for report creation. The scenario starts with creating a new Project report

which is the foundational step. (See section "Create a report").

2. Adobe Experience League Documentation - Add a prompt to a report: This source details how to add prompts

which are essential for user-selectable criteria. The document states

"You can add a prompt to a report to allow people who view the report to specify a filter for the information they see." This directly supports using a prompt for 'Portfolio Name'. (See section "Add a prompt to a report").

3. Adobe Experience League Documentation - Edit report settings: This guide explains how to access the settings to modify a report

including adding prompts. The path described in option A

"From the Reporting Settings dropdown

add a prompt

" aligns with the UI described here. (See section "Report Settings area").

4. Adobe Experience League Documentation - Sort information in a list: This document confirms the ability to sort columns in reports. It explains how to apply a descending sort to a column like 'Actual Cost' to list the highest values at the top. (See section "Sort by one column").

The most direct and accurate method to fulfill the request is by using the dedicated Calendars area in Adobe Workfront. This approach allows for the creation of a calendar view by defining the object type (projects), specifying the date field to be displayed (Planned Dates), applying a filter for the specific project manager (Project Owner ID), and setting a single, static color (purple) for all displayed entries. This process aligns perfectly and efficiently with all the user's requirements.

A: This option is incorrect because it states that the color should be set in the filter ("set the Color ID field to purple"). In Workfront, color is a display property configured in the View settings, not a filterable attribute.

C: This option is incorrect for two reasons: you create a report (not a calendar) on the Reports page, and it incorrectly places the color setting within the filter. It also fails to mention applying the calendar view.

1. Adobe Workfront Documentation

"Get started with Calendars": This document outlines the procedure for creating a calendar directly from the Calendars area. It states

"Go to the Main Menu > Calendars... Click New Calendar." It then details the steps for adding items (like projects)

applying filters

and configuring display options

which includes setting the color for calendar entries. This supports the process described in option B.

2. Adobe Workfront Documentation

"Create a calendar report": This guide details how to apply a calendar view to a standard report. In the section "Customize the calendar view

" it explains how to configure event coloring under "Style events by

" where you can select "A single color for all events." This confirms color is a view setting.

3. Adobe Workfront Documentation

"Create or edit a filter in Adobe Workfront": This source provides a comprehensive list and explanation of available filterable fields. There is no "Color ID" field or any similar attribute that would allow a user to filter objects based on a display color

confirming that the method described in options A and C is not possible.

In Adobe Workfront reporting, date-based wildcards are used to create dynamic filters. The wildcard TODAY represents the current date. To filter for a date one month in the future, you append +1m, where m specifically designates a calendar month. Therefore, TODAY + 1m correctly and precisely represents a date exactly one calendar month from the current date, fulfilling the requirement to filter for projects with a planned completion date greater than this value.

A. TODAY + 1bm: This is incorrect because bm stands for "business month," which may differ from a calendar month depending on the system's fiscal calendar configuration. The question specifies a generic "month."

C. CURRENTDATE + 4w: This is incorrect because 4w represents four weeks (28 days). This is not equivalent to a calendar month, which can have 28, 29, 30, or 31 days, making the filter inaccurate.

1. Adobe Experience League - Workfront Documentation. "Wildcard filter variables". In the section "Date-based wildcards

" the documentation explicitly lists m as the modifier for "month" and provides examples of its usage (e.g.

$$TODAY+1m). It also lists w for "week" and bm for "business month

" clarifying the distinction between the options.

Reference Location: Adobe Experience League > Workfront > Reporting > Create and manage reports > Filters > Wildcard filter variables.