Adobe Workfront PM Professional common mistakes
Adobe Workfront PM Professional · Understand the traps and how to avoid them.
Setting up a request queue by building a custom form, adding a user picker or 'assign to' field on that form, and expecting new requests to route to the right person - the Queue Details tab and its routing rules are never configured.
Candidates memorise 'requests = custom form + queue topic' and stop there, so they never learn that assignment comes from Queue Details → Routing Rules (or a queue topic's default routing), not from a field a requester fills in.
What to do instead
Drill the three-part model: a project becomes a queue only when 'Publish as Help Request Queue' / Queue Details is enabled; queue topics supply the default custom form, default approval and default routing; routing rules on Queue Details decide whether the issue lands on a user, team, job role or another queue. Practise building one queue with two topics and two different routing rules and verify in the Issues tab which owner and form each request receives.
Explaining what carries over when an issue (request) is converted to a project, and confidently claiming that the original status, approval history and assignments move to the new project.
Conversion feels like a 'copy everything' operation, and the visible result (a new project with the same name) reinforces that intuition, so candidates never check the transfer list.
What to do instead
Learn the conversion dialog controls instead of guessing: you choose the conversion type (project or task), can convert and keep the original issue as a 'resolved issue' linked to the new object, and the transfer is limited to the name, custom form values for fields that exist on the new object's form, documents, updates and the primary contact/owner relationship. Status, approvals and work assignments do not migrate - they are set on the new project.
Changing Planned Hours or adding a second assignee on a task and then predicting the wrong new Duration (or wrong per-user hours) because the task's Duration Type was never checked.
Candidates treat Duration, Planned Hours and assignments as independent fields. They are linked, and Duration Type is the switch that decides which one recalculates and which one is held fixed.
What to do instead
Memorise the behaviour of each Duration Type rather than reciting definitions: Calculated Assignment and Calculated Work re-derive duration/hours when assignments or hours change; Effort Driven keeps total planned hours constant and redistributes them across assignees; Fixed Dates leaves the planned dates alone regardless of duration or hours changes. Practise by taking one 8-hour task, adding a second assignee, and watching duration under each type.
Trying to schedule a task off work in another project and either giving up ('cross-project predecessors aren't possible') or typing the task number directly into the Predecessors field, then misreading the resulting dependency.
The Predecessors field looks like it only accepts tasks in the current project, and the display format for an external predecessor differs, so candidates assume the feature is unavailable or misconfigure that entry.
What to do instead
In the task's Predecessors field, start typing the project name to search across projects, then pick the task; the saved dependency displays as ProjectName: TaskName, and you must have rights to the other project. Also learn lag syntax - '2d' is working days and '2e' is elapsed days - because the wrong suffix is the usual reason a dependency date looks wrong after recalculation.
Assuming a task automatically flips to Complete at 100% Percent Complete (or, conversely, marking a task Complete and expecting Percent Complete to become 100) without checking the Completion Mode setting.
Completion Mode is a preferences-level setting (Automatic vs Manual, and the same concept exists for parent tasks), so it is invisible on the task itself and candidates never look for it.
What to do instead
Learn that with Automatic completion mode Workfront sets the status to Complete when Percent Complete reaches 100 and vice versa, while Manual mode requires the user to set status and Percent Complete separately - and that summary/parent task completion follows its own mode. When a scenario says the percent and the status disagree, the answer is almost always Completion Mode, not a permission or an approval.
Using the Resource Planner to answer a day-to-day 'who is overloaded this week and where do I move the work' question, or using the Workload Balancer to answer a quarterly job-role capacity question.
Both screens show bars and hours, so they look interchangeable; the distinguishing inputs (assignments vs budgeted hours and job roles) are off-screen.
What to do instead
Separate them by data source: the Workload Balancer works off actual task/issue assignments and planned hours, supports drag-and-drop rebalancing and unassigned work, and is the tool for near-term reallocation; the Resource Planner works off budgeted hours by job role in initiatives/projects, requires the resource pools and job role setup, and answers longer-range capacity questions. Read the scenario for the words 'assigned', 'budgeted' and 'job role' - they point to different tools.
Writing a report filter that should match either of two values by putting both lines in the filter, e.g. status=CPL and status=INP, and getting zero results - then abandoning text mode for a worse workaround.
The standard filter builder silently ANDs lines, and text mode does not visibly group conditions, so candidates never learn the OR prefix syntax.
What to do instead
Learn the two text-mode idioms for OR: the OR prefix form (status=CPL on the first line, then OR:1:status=INP on the next line, with the number grouping the conditions that belong together) and the Modifier form (status=CPL / status_Mod=in with INP on the following operator line). Rebuild the filter in text mode, run it, and confirm the result count changes so you have seen the syntax work.
Building a Task report that also pulls assignment or custom-form data, then reporting hours totals that are inflated because each task now appears once per assignee (or per multi-select value).
The one-to-many relationship between tasks and assignments is invisible in the report builder preview, and the row count only looks wrong if you compare it to the number of tasks.
What to do instead
Choose the reporting element that matches the grain of the question: an Assignment report (or a Task report filtered with an EXISTS filter on assignments) when you need one row per assignee, and aggregation in a valueexpression when you need a true total. As a rule, do not place assignment-level columns on a task-level report unless you have deliberately accepted the row multiplication, and always sanity-check row count against object count.
Treating Agile as 'the board view' - assuming iterations are mandatory, that Story Points and Planned Hours are the same measure, and that a Kanban board's columns are the same as a Scrum iteration's story board.
Newer Workfront releases push Boards as a general work-management surface, which blurs the line between the team Agile tool (Scrum/Kanban with iterations and backlog) and ad-hoc boards, so candidates skip the team-level Agile settings.
What to do instead
Pin down three facts: a team's Agile configuration (Scrum vs Kanban, default board type, how many iterations are shown) is set per team, not per project; iterations are created and scoped for Scrum teams while Kanban teams work continuously from a backlog with WIP limits per column; and Story Points are a separate field from Planned Hours - a report can sum one without the other, which is where most story-point/velocity questions go wrong.
Assuming an approval decision on a proof automatically updates the document's approval status or the linked task's status - and that proof stages and document approvals are the same mechanism.
There are three overlapping approval mechanisms (proof approval workflow with stages, document approval, and task/issue/project approvals), all surfaced on the Documents and Updates tabs, so the first one learned gets applied to all scenarios.
What to do instead
Keep the objects distinct: a proof carries its own approval workflow (stages, reviewers, roles like Approver/Reviewer, and a decision), which is separate from the lightweight approval you can place on the document itself, and separate again from the approval on the task or project. A proof decision is recorded against the proof version; it does not silently flip the task status. When a scenario asks what happens after a reviewer rejects, answer in terms of the proof's stage and version, not the object's status.
Explaining why a user cannot see a project by pointing at their Access Level ('they're a Planner, they should see everything') or at the layout template, rather than at sharing on the object or group/team membership.
Access Levels, layout templates, sharing and group membership all live in Setup and all sound like 'permissions', so candidates collapse them into one concept and pick whichever they reviewed last.
What to do instead
Sort them by job: Access Level = licence-based capability (can this user edit projects at all), Layout Template = what they see in the interface, object Sharing = whether they can see this specific project; a Planner with no share, no team, no group membership and no portfolio access still sees nothing. Practise one 'user cannot access project X' scenario by walking the chain in that order - access level, then share/team/group, then layout template - and note which link actually breaks.