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

To meet the requirements, the System Administrator must configure two key settings within the timesheet profile. First, to ensure timesheets are generated automatically, the "Generate a timesheet" setting must be configured with a specific time interval, such as "Every Week." Second, to route these timesheets to the user's manager for approval, the "Approvers" field must be set to the dynamic option "Their Manager." This ensures the system automatically creates the timesheet on a schedule and directs it to the correct approver as defined in the user's profile.

C. Provide detailed description of the timesheet profile: A description is for administrative clarity and does not affect the functional behavior of timesheet generation or approval routing.

D. Specify projects to appear on the timesheet: This setting pre-populates the timesheet with specific projects for easier time logging but does not control the automatic creation or the approval workflow.

1. Adobe Workfront Documentation - Create and manage timesheet profiles:

Section: Create a timesheet profile: This section details the configuration options. For automatic generation (Answer A), it describes the "Generate a timesheet" setting where an administrator selects the frequency (e.g., "Every Week," "Every Other Week"). For approval routing (Answer B), it describes the "Approvers" field, explicitly mentioning the "Their Manager" option to route the timesheet to the manager of the user who submitted it. This source also implicitly confirms options C and D are incorrect for the stated goal, as their functions are described as informational (Description) and for pre-population (Projects), respectively.

Source: Adobe Experience League. "Create and manage timesheet profiles." Accessed May 2024.

In Adobe Workfront, an issue represents unplanned work, a bug, or a problem that needs to be addressed. When an issue requires more substantial effort than a simple fix, it can be escalated. The system provides two direct conversion paths for an issue: it can be converted into a task, which is then added to an existing project, or it can be converted into a new, standalone project. This allows teams to properly scope, plan, and track the resolution work using standard project management tools.

B. Update: An update is a comment or a status change associated with a work item; it is not a work object that an issue can be converted into.

D. Request: A request is an initial intake item submitted to a request queue. An issue is typically identified during a project, not converted back into a request.

1. Adobe Experience League Documentation, "Convert an issue in Adobe Workfront."

Reference: The introductory paragraph explicitly states: "You can convert an issue to a task or a project when you realize that the work required to complete the issue is more involved than you originally thought." This document details the procedures for both conversion types.

Source: https://experienceleague.adobe.com/docs/workfront/using/work-in-an-agile-environment/agile-issues/convert-issues.html?lang=en (Accessed under the sections "Convert an issue to a project" and "Convert an issue to a task").

According to the Adobe Workfront licensing model, the ability to create, edit, and delete reports is a high-level function reserved for users with specific license types. The Plan license, designed for portfolio and program managers, and the Standard license (the current designation for the Work license), designed for project managers, both provide these capabilities. These licenses grant users the necessary permissions to build and manage reports for tracking projects, resources, and portfolios, assuming their assigned access level also permits it. The other license types mentioned are designed for users with more limited roles who do not require report-building functionality.

A. The Light license (a legacy type, similar to the modern Review license) is for users who primarily update tasks or review content; it does not include permissions to create, edit, or delete reports.

B. This option is incorrect because "Work" is the conceptual name for the license officially designated as "Standard" in the current model. Including both terms is redundant and imprecise for an exam context.

1. Adobe Workfront Documentation, "Adobe Workfront licenses overview." This document outlines the different license types. It states, "The following sections describe the new licenses: Plan, Work, Review, Request." It also includes a note clarifying the terminology: "The Standard license is the new Work license." This establishes that "Standard" is the current license name for the user type that manages work.

Reference: Adobe Experience Cloud. (2024). Adobe Workfront licenses overview. Adobe Workfront Documentation. Retrieved from https://experienceleague.adobe.com/docs/workfront/using/workfront-basics/workfront-licenses-overview.html (Refer to section "The new Workfront licenses" and the subsequent note on the Standard license).

2. Adobe Workfront Documentation, "Create a report." This article specifies the license requirements for reporting. It states, "You must have a Plan or Work license for Adobe Workfront to create a report." Given the clarification from the license overview, this requirement applies to users with a Plan or Standard license.

Reference: Adobe Experience Cloud. (2024). Create a report. Adobe Workfront Documentation. Retrieved from https://experienceleague.adobe.com/docs/workfront/reports-and-dashboards/reports/creating-and-managing-reports/create-report.html (Refer to the "Access requirements" section).

3. Adobe Workfront Documentation, "Grant access to reporting." This document details the permissions related to reporting, which are inherently tied to the user's license type. It confirms that creating, editing, and deleting reports are permissions granted to higher-level licenses like Plan and Standard/Work.

Reference: Adobe Experience Cloud. (2024). Grant access to reporting. Adobe Workfront Documentation. Retrieved from https://experienceleague.adobe.com/docs/workfront/add-ons/adobe-workfront-for-experience-manager-assets-essentials/administration-and-setup/grant-access-to-reporting.html (Refer to the "Access to reports, dashboards, and calendars" table).

To ensure consistent project data for reporting, a standardized data collection method is required for all new projects. This is achieved by creating a Custom Form with the desired data fields and attaching it to a project template. When a new project is created from this template, it automatically includes the Custom Form (D). Furthermore, to enhance consistency and reduce manual entry, the custom fields on that form can be pre-populated with default or calculated values, ensuring key data points are present from the project's inception (A).

B. Custom fields provide the data used in dashboards, but they do not dictate the structure, layout, or consistency of the dashboards themselves. Dashboards are configured separately.

C. Identifying the best available resource is a function of resource management tools like the Workload Balancer and Resource Planner, not a capability of Custom Forms.

1. Adobe Workfront Documentation, "Add a custom form to an object": This document explicitly states, "You can attach a custom form to a project template. When a user creates a project using the template, the custom form is automatically attached to the new project." This directly supports option D as the mechanism for ensuring consistent application of data fields.

Source: Adobe Experience League, Adobe Workfront Documentation. Article ID: 000013383.

2. Adobe Workfront Documentation, "Create or edit a custom form": When adding fields (like a Text field) to a Custom Form, the configuration options include setting a "Default Value." This demonstrates that fields can be pre-populated with data to ensure consistency, supporting option A.

Source: Adobe Experience League, Adobe Workfront Documentation. Article ID: 000013381.

3. Adobe Workfront Documentation, "Overview of calculated custom data expressions": This source details how calculated fields can be used to automatically populate data based on expressions. The documentation notes, "You can use calculations to automatically populate a custom field on a custom form," which is a method of pre-populating data as described in option A.

Source: Adobe Experience League, Adobe Workfront Documentation. Article ID: 000013401.

In Adobe Workfront, custom statuses can be created at the system level or for specific groups. To meet the requirement that not all users need access to these new statuses, the administrator must scope them. This is achieved by creating the custom statuses within the settings of a specific Group. By associating the statuses with the group that owns the relevant projects, only users and projects within that group will be able to see and use them, effectively segmenting their availability from the rest of the system.

A. User profiles do not have a "Status Settings" area for creating custom statuses. Statuses are a system or group-level configuration, not a personal user setting.

C. While Agile teams use custom statuses on storyboards, the storyboard is a tool for visualizing and using statuses, not for creating them. The fundamental administrative action is creating the status for the group in the Setup area.

1. Adobe Workfront Documentation - Create or edit a group status:

"As a group administrator, you can create custom statuses for the groups you manage. The statuses you create are available only for objects associated with that group."

Location: Adobe Experience League > Workfront Documentation > Administrator Guide > Set up Workfront > Create and manage Groups > Create or edit a group status. (This article explicitly details the process described in option B).

2. Adobe Workfront Documentation - System-wide vs. group-specific statuses:

"Statuses can be created for the entire Workfront system or for a specific group. ... When you create a status for a specific group, only users associated with that group can see and apply the status to the objects they work on."

Location: Adobe Experience League > Workfront Documentation > Administrator Guide > Set up Workfront > Project Preferences > Statuses > System-wide vs. group-specific statuses. (This section clarifies the scoping mechanism central to the question).

When building a custom form with conditional logic, a developer must understand the default behavior of fields and the limitations of the logic types. By default, all custom fields added to a form are visible unless a specific display logic rule is created to hide them. This is a foundational principle for the developer to consider when deciding which fields need rules. Additionally, it is a critical technical limitation that skip logic cannot be applied to non-input elements like widgets or section breaks; it can only target fields. This directly impacts how the developer must structure the form to achieve the desired conditional navigation.

A. When a custom form is copied, all associated display and skip logic rules are copied with it, which is contrary to the statement.

B. When bulk editing, fields hidden by display logic are displayed in the edit dialog, as the logic cannot be evaluated across multiple, potentially different, objects.

1. Adobe Workfront Documentation, "Add display logic and skip logic to a custom form."

For Answer C: In the "Overview of display logic" section, it is stated: "By default, all fields, widgets, and section breaks you add to a custom form are visible to users." This confirms that fields not included in a display logic statement are shown by default.

For Answer D: In the "Skip logic" section, a note explicitly states: "You cannot apply skip logic to a widget or a section break." This confirms the limitation.

2. Adobe Workfront Documentation, "Copy a custom form."

For Incorrect Option A: The article states, "When you copy a custom form, any display and skip logic on the form is also copied." This directly refutes option A.

3. Adobe Workfront Documentation, "Edit information for multiple projects in a list."

For Incorrect Option B: Under the section "Understand how custom forms work with bulk editing," it explains: "Fields that are revealed by display logic in a custom form are always displayed when you edit objects in bulk using that form." This refutes option B.

An automated workflow template is the specific Adobe Workfront feature designed to standardize and automate multi-stage review and approval processes for proofs. This allows an administrator to create a reusable template with a first stage routing the proof to the user's team for feedback. A subsequent, second stage can then be configured to automatically route the proof to the manager for final approval only after the first stage is complete. This directly addresses the customer's need for a consistent, sequential approval process for their proof assets.

B. Create a global two-stage approval process with the team and manager added in separate stages

Global approval processes apply to Workfront objects like projects, tasks, or issues, not directly to the proofing lifecycle itself. An automated workflow is the specific tool for proofs.

C. Create a proof approval associated to a task in the project template assigned to the team and manager

This option implies a single approval step assigned to both the team and manager simultaneously, failing to meet the requirement for a sequential, two-stage process (team first, then manager).

1. Adobe Workfront Documentation, "Automated workflow overview." This document states, "To standardize your proofing process, your Adobe Workfront administrator or a user with a Planner license can create automated workflow templates... You can add multiple stages to an automated workflow template to manage your review process." This confirms that automated workflows are the correct tool for standardized, multi-stage proof reviews.

2. Adobe Workfront Documentation, "Create an advanced proof with an automated workflow." Under the section "Apply an automated workflow to a proof," the documentation details the process of selecting a pre-configured template when uploading a document. This template contains the predefined stages, reviewers, and deadlines, ensuring consistency as required by the question.

3. Adobe Workfront Documentation, "Configure a proofing workflow template." This guide explains the setup process, specifically mentioning the ability to "Add stages to the workflow" and "Add reviewers to a stage," which is precisely what is needed to configure the team review stage followed by the manager approval stage.

A user's Available Hours (AVL) in the Adobe Workfront Resource Planner are calculated based on their defined work capacity. This capacity is determined by their schedule, modified by their Full-Time Equivalent (FTE), and reduced by any scheduled time off. An FTE value of less than 1.0 indicates the user works part-time, which proportionally reduces their total available hours from the system's default schedule. Similarly, any days designated as Time Off for a user are subtracted from their schedule, directly decreasing their availability for that period.

A. Planned hours are the hours allocated to a user from their available capacity; they do not determine the initial availability itself but are used to calculate variance.

D. Deactivating a user removes them from active resource pools entirely, typically resulting in zero availability, rather than adjusting the hours of an active resource.

1. Adobe Workfront Documentation, "Calculate User Availability": The official documentation explicitly states the formula for user availability: User Availability = (Default Schedule Hours FTE) - Exceptions - Time Off. This formula directly confirms that both FTE and Time Off are primary inputs for calculating available hours. (Reference: Adobe Experience League, Workfront Documentation, Article ID: 000013388, "Calculate User Availability" section).

2. Adobe Workfront Documentation, "Edit a user's profile": In the section describing user profile fields, the "FTE" (Full Time Equivalent) field is defined. It specifies that this value adjusts the user's availability based on the percentage of a standard schedule they work. For example, an FTE of 0.5 for a 40-hour default schedule results in 20 available hours. (Reference: Adobe Experience League, Workfront Documentation, Article ID: 000013373, "Edit a user's profile," section on "Personal Info").

3. Adobe Workfront Documentation, "Enter time off for a user": This document explains that when time off is entered for a user, "Workfront considers them unavailable for work during that time." It further clarifies that this unavailability is reflected in resource management tools, including the Resource Planner, by reducing their available hours. (Reference: Adobe Experience League, Workfront Documentation, Article ID: 000013377, "Enter time off for a user" section).

In Adobe Workfront, when a status is created and designated as a "group status," its availability is restricted. For this custom status to appear on tasks within a specific project, the project itself must be formally associated with that same group. This association is configured in the "Project Details" section. The presence of team members from the group on the project team is not sufficient to make the group status available; the project-to-group link is the determining factor. This explains why the status is missing in some projects even if they have members from the relevant group.

A. The presence of team members not associated with the Marketing group does not prevent a Marketing group status from being available. Availability is determined by the project's association with the group, not the composition of the project team.

B. Adobe Workfront does not have a general project-level setting to simply "toggle on" the use of all custom statuses. The availability of specific statuses is managed through system-wide and group-level configurations.

1. Adobe Workfront Documentation - Create and customize system-wide statuses: "When you create a status and associate it with a group, only users in that group can use it. For users to be able to use a group status on an object, the object must also be associated with the same group." This is further detailed in the section "Create or edit a status," which explains the process of associating a status with a group.

Source: Adobe Workfront Documentation, "Experience League > Workfront > Administration and setup > Project setup > Create and manage statuses > Create and customize system-wide statuses."

2. Adobe Workfront Documentation - Associate objects with a group: "You can associate certain objects with a group that you manage to make group-specific items available to them. For example, if you want to use a custom form or a status that is specific to your group on a project, you must associate the project with your group."

Source: Adobe Workfront Documentation, "Experience League > Workfront > Administration and setup > Group administration > Associate objects with a group."

In the Adobe Workfront data model, work items are organized hierarchically. A project, as a singular entity, can be associated with only one program and one portfolio at any given time. This ensures clear ownership, reporting, and management alignment. Tasks are child objects of a project; therefore, they inherit the project's association with its parent program and portfolio. This one-to-one relationship (a project to a single portfolio/program) is a fundamental structural constraint within the Workfront system.

A. Projects can exist as standalone entities in Workfront and are not required to be associated with either a program or a portfolio.

C. A project can be associated with a program at any point after its creation; this action is independent of and not contingent upon the existence of tasks within the project.

1. Adobe Workfront Documentation, "Add projects to a program": This guide details the process of associating a project with a program. The interface shown and the steps described involve selecting a single program for a project, and there is no mention of a prerequisite for tasks to exist. This supports the rejection of option C and the exclusivity principle of option B. (Source: Adobe Experience League, Workfront Documentation, "Add projects to a program," Section: "Add a project to a program from the project's page").

2. Adobe Workfront Documentation, "Create a project": The documentation for creating a project shows that "Portfolio" and "Program" are fields where a user selects a single value from a list. This user interface design enforces the constraint that a project can only belong to one of each at a time, directly supporting answer B. (Source: Adobe Experience League, Workfront Documentation, "Create a project," Section: "Create a project from scratch," Step 10 under "New Project" details).

3. Adobe Workfront Documentation, "Portfolios in Adobe Workfront": This overview describes a portfolio as a "collection of projects." The entire model is based on grouping unique projects. The documentation does not describe any mechanism for a single project to exist simultaneously in multiple portfolios, reinforcing the one-to-one relationship. (Source: Adobe Experience League, Workfront Documentation, "Portfolios in Adobe Workfront," Overview section).

The "Reviewer & Approver" role is recommended when a user needs to do more than just provide feedback. This role uniquely grants the ability to make a formal decision on the proof (e.g., Approved, Changes Required, Not Relevant). This decision acts as a definitive summary of their overall feedback (B) and serves as a formal mechanism to indicate that their review is complete, even if no specific comments or markups were added (A). A standard "Reviewer" can only add comments and cannot make these binding decisions.

C. This is incorrect because the standard "Reviewer" role also allows for making comments and markups; this capability is not exclusive to the "Reviewer & Approver" role.

D. Notifications are configured within the proof's workflow settings and are not a primary function or reason for assigning a specific user role like "Reviewer & Approver."

1. Adobe Workfront Documentation, "Proof roles overview." This document explicitly outlines the capabilities of each role. It states that both "Reviewer" and "Reviewer & Approver" can "Make comments and markups," invalidating option C. It also specifies that only roles with "Approver" permissions can "Make a decision on the proof," which directly supports options A and B as the key differentiator.

2. Adobe Workfront Documentation, "Make a decision on a proof in the proofing viewer." This guide details the decision-making process for approvers. It states, "As an approver on a proof, you must make a decision on the proof to indicate whether it's ready for the next step in its lifecycle." This confirms that making a decision is the formal method for an approver to complete their review and summarize their findings, supporting the reasoning for answers A and B.

Connected cards are the specific feature within Adobe Workfront designed to link a card on a board to an existing project object, such as a task or an issue. When a team member updates the status of a connected card on the board (e.g., moving it to a "Done" column), the progress is automatically synchronized with the corresponding task in the project plan. This mechanism provides the project manager with accurate, real-time visibility into the progress of project-related work being managed by an agile team on a board, ensuring alignment between the board and the project.

A. Through ad hoc cards: Ad hoc cards are used for unplanned work or tasks that are not associated with a formal project, so they do not track progress against a project.

B. Through enabling agile tracking: "Agile tracking" is a broad methodology or practice, not a specific tool feature that connects a board card to a project task for progress updates.

1. Adobe Experience League Documentation, "Use connected cards on a board." This document explicitly states, "You can connect cards to existing Workfront objects, such as tasks or issues. This allows you to manage the work on the card and have the progress automatically update on the connected object." (See the "Overview of connected cards" section).

2. Adobe Experience League Documentation, "Create ad hoc cards on a board." This source clarifies the purpose of ad hoc cards: "You can create ad hoc cards on a board to represent work that is not tied to a Workfront object." This confirms they are not for tracking progress within a project. (See the introductory paragraph).

3. Adobe Experience League Documentation, "Boards overview." This document provides context on the different types of cards: "Cards on a board can be ad hoc cards (standalone cards that are not connected to other Workfront objects) or they can be connected to tasks and issues on projects." (See the "Cards" section).

In Adobe Workfront, the "Card Falloff" feature is specifically designed to automatically remove cards from a board after they have resided in a designated column for a specified period. To implement this, the project manager must access the board's configuration settings. The correct path is to navigate to the board's Configure menu, select the Cards section, and then enable the Card Falloff option. Within this setting, they can specify the "Closed" column and set the time period to 14 days (two weeks) for automatic archival.

B. Select the Closed column > select Edit and set Archive Limit to two weeks

Editing a column directly typically allows for changing its name, Work-In-Progress (WIP) limit, or policies, not for setting time-based archival rules.

C. Select the three ellipses next to the board name > select Archive and set for two weeks.

This action would pertain to archiving the entire board, not for setting up an automated rule to archive individual cards from a specific column.

1. Adobe Workfront Documentation - Configure cards on a board:

"You can configure cards to automatically fall off a board after a specified number of days. When a card falls off a board, it is removed from the board but the associated task or issue is not deleted."

The procedure is detailed as: "Click the More menu ... then click Configure. ... In the left panel, click Cards. ... In the Card Falloff section, select the checkbox to enable card falloff. ... Select a column from the drop-down menu. ... Specify the number of days..."

Source: Adobe Experience League, "Configure cards on a board," Workfront Documentation. (Specific section: "Enable card falloff").

To ensure users can both use a template and access the projects created from it, two distinct sharing configurations on the template are required. Template Sharing controls which users can view and select the template to create a new project. Project Sharing defines the access permissions that are automatically inherited by any new project created from that template, granting the specified users access to the resulting project instance. Both must be configured to fulfill the complete requirement.

C. Template Group: This is not a specific configuration item in Adobe Workfront. While you can share a template with a group, "Template Group" is not the name of the setting itself.

D. Team Sharing: This is a method of sharing, not a fundamental configuration item. You can share with a team, but the core settings are "Template Sharing" and "Project Sharing."

1. Adobe Workfront Documentation - Share a project template:

Section: "Access to the template and to the projects created from it": "When you share a template, you can also grant users access to the projects that are created using the template. You grant access to the template and to the projects created with it separately."

Section: "Share a template": This section details the steps for configuring "Template Sharing" which "gives them access to use it to create projects."

Section: "Configure sharing for the projects created with the template": This section explains how to use the "Project Sharing" tab to "grant users access to the projects that are created using the template." This directly supports the distinction between the two required settings.

(Source: Adobe Experience League, "Share a project template", Workfront Documentation. Document ID: 000013988)

In Adobe Workfront, billing rates are used to calculate project revenue and are foundational for financial management. The system allows for the creation of date-effective billing rates, which means different rates can be applied for the same object over different time periods. According to official documentation, these billing rates can be specifically created for and associated with three types of objects: Companies, Users, and Job Roles. This allows for granular control over billing, accommodating rate changes over time for specific clients (Companies), individuals (Users), or functional positions (Job Roles).

A. Job roles. Users. Groups: Workfront does not support the direct association of billing rates with Groups. Groups are primarily used for managing user access and permissions, not for financial rate structures.

C. Users. Teams. Job Roles: Billing rates cannot be directly applied to Teams in Workfront. Teams are organizational units for work assignment and collaboration, not for defining financial rates.

1. Adobe Experience League, Workfront Documentation. In the article "Create and manage billing rates," the introduction explicitly lists the objects for which billing rates can be created.

Reference: "You can create billing rates for the following items in Workfront: Companies, Job Roles, Users."

Source: Adobe Experience League, Create and manage billing rates, Section: "Create and manage billing rates".

2. Adobe Experience League, Workfront Documentation. The same document details how to create date-effective rates, which is a property of the billing rate record that is then associated with the supported objects.

Reference: The section "Create date-effective billing rates" explains the concept of having multiple rates for different time periods, a feature applicable to the billing rates associated with the objects listed above (Companies, Users, Job Roles).

Source: Adobe Experience League, Create and manage billing rates, Section: "Create date-effective billing rates".