Adobe Workfront PM Professional cheat sheet

A request queue requires three components: a project acting as the queue, a queue topic (routing rule) with custom form fields, and access/permission to submit.

Queue topics route incoming issues to different groups or assignees; topic group and topic channel rules determine which fields appear per topic.

Routing rules map a request to a specific queue, topic, and default assignee; they fire on request submission and can be scoped by custom form values.

Converting an issue to a project keeps the issue record as an audit trail; a resubmitted request creates a new resolving object link.

A request can be converted to a project only if the user has Convert permission and the issue is not already resolved by a project.

Custom forms attach via object types (Project, Issue, Task, Portfolio, Program); a request queue custom form becomes the intake questionnaire.

Approval on intake: associate an approval process with the queue topic or the project; the request stays pending until all decisions are recorded.

Business case inputs (cost, risk, ROI) feed the Portfolio Optimizer; the business case must be submitted and scored before it appears in optimization scenarios.

Task duration is the number of working days between planned start and planned completion; it excludes weekends and non-working time per schedule.

Predecessor relationships: Finish-Start (FS) default, Start-Start (SS), Finish-Finish (FF), Start-Finish (SF); lag uses positive or negative days.

Work effort = total hours of work; and Work Required combination determines duration: Calculated Assignment (duration derived from hours), Calculated Work (work derived from duration), Fixed Dates (constrained), or Effort Driven.

Duration Type (Simple, Effort Driven) plus a work/assignment calculation mode governs how changes to assignments affect work and duration.

Task constraints: As Soon As Possible, As Late As Possible, Must Start On, Must Finish On, Start No Earlier Than, Start No Later Than, Finish No Earlier Than, Finish No Later Than, Fixed Dates.

A milestone has duration zero and no work; it holds a date marker for approvals or deliverables.

Critical Path is the longest path of dependent tasks with zero float; tasks with zero float are critical.

Planned hours on a task sum across assignments; the task Planned Cost equals planned expense plus planned hours x cost per hour of assigned job roles or users.

Schedules define working days, working hours, and exceptions (holidays); the project schedule drives all date and duration calculations.

Task statuses map to progress: New, In Progress, Done; percent complete is derived from status unless manually entered with a duration percent complete override.

Commitment dates are user-entered promises; Planned Completion Date is system-computed from scheduling - the two diverge when constraints or leveling push dates.

Use the Updates tab and @mentions for auditable project communication; updates are searchable and appear in reports via the Journal/Note fields.

Issue (request) vs Task: issues can be converted to tasks; tasks belong to project plan structure and roll up percent complete to the parent project.

Approvals on tasks run through approval processes attached at the task level or global approval settings; rejection sends the task back to a prior status.

Percent Complete mode on a project can be Duration, Effort, or Manual; it determines how summary progress is calculated across child tasks.

Task predecessors must be on the same project (or cross-project with the correct permissions); cross-project predecessors refresh via recalculation.

Bulk edits via the task list allow status, assignee, and custom field updates; changes recalculate the project schedule when Automatic Recalculate is on.

Resource Planner uses planned hours from projects, initiatives, and job role requests over a chosen timeframe to show role-based demand vs. available FTE or hours.

Workload Balancer shows assigned work by user with task and issue level breakdowns, including unassigned work in the backlog area for potential assignment.

Available hours = user's schedule working hours minus exceptions minus time off, adjusted by FTE percentage on the user record.

Allocation percentage on a job role or user affects available hours; over-allocation shows as red in the Workload Balancer.

Scenario planning in the Resource Planner compares adjusted planned hours per role against capacity to price out alternatives before committing.

Job role demand can be captured at the project or task level; the Resource Planner aggregates by job role across portfolios and programs.

Utilization report shows allocated hours vs. available hours per user; utilization over 100 percent indicates overallocation.

Team and group membership define the pool of users visible in resource management tools; the user's Home Group drives sharing and reporting scope.

Report types (Project, Task, Issue, Hour, User, Portfolio, etc.) each expose only the fields and objects relevant to that object's data model.

Text Mode adds what the UI does not expose: valuefield, valueexpression, aggregation, displayname; filters use field, operator, and value rows in text mode.

Filters combine with AND between rows by default; nested OR logic requires Text Mode with an OR:1 prefix or field groupings.

A dashboard holds up to 25 reports/sections; the dashboard layout is a grid of columns and rows per section.

Prompt filters let viewers change report values at runtime; prompts on dashboards can be shared across all reports on the dashboard.

Aggregation options: Sum, Count, Average, Min, Max, and distinct count for certain field types; text mode valueformat controls number/date/currency display.

Report sharing uses the access levels plus sharing rules; running a report as another user requires Manage access and the 'Run this report with the access rights of another user' setting.

Deliverables schedule reports via recurring email deliveries; the delivery respects the report's filter at run time, not at creation time.

A Kanban board maps columns to statuses and shows incoming backlog; a Scrum board uses iterations and a story board with a team-based backlog.

An Agile team defines the users, iterations cadence, and story point estimates; a team can own multiple boards but an iteration is scoped to one team.

Backlog order is the team's prioritization; the top of the backlog is what the team pulls into an iteration.

Story points are estimated per task/story; velocity is completed points per iteration, and burndown tracks remaining points across iteration days.

Iteration dates must not overlap for the same team; completing an iteration moves incomplete items back to the backlog by default.

Burndown chart derives from story points (or hours) planned vs. remaining; scope change mid-iteration appears as a jump in the ideal line versus actual.

A board card represents a task or issue; card status change updates the underlying object status and the project's percent complete.

Workfront Boards (the newer card-based tool) connect to Workfront records; the area and card columns can be configured independently of project statuses.

Proofing workflow: upload a proof on a document, add a proof workflow (Basic, Automated, or Stage-based), then reviewers mark decisions.

Proof decisions: Approved, Approved with changes, Changes required, Not relevant; the overall proof status completes only when every stage and recipient is decided.

Automated Workflow deadlines per stage; a stage advances when the minimum number of decisions is reached according to the workflow settings.

Proof roles: Reviewer, Approver, Author, Moderator; a Guest reviewer does not need a Workfront license but must be added to the proof.

Document approvals (non-proof) apply to documents without a rendered proof; proof approvals apply when markup and versions matter.

Version control: uploading a new proof version retains prior version comments; the combined status across versions affects document approval status.

Approval processes have stages, each with approvers and a required decision count (one or all); if a stage is rejected, the object's status reverts per the process definition.

Commenting on proofs supports annotations, markup tools, and @mentions that notify reviewers; all comments are retained in the proof activity log.

Access levels (Planner, Worker, Reviewer, Requester) set the maximum permissions; sharing on objects can only further restrict, never exceed, the access level.

Layout templates control tabs, fields, and sections users see; a layout template applies per user, group, job role, or default for new users.

Custom forms and fields: field types (text, dropdown, multi-select, calculated, reference) determine reporting behavior; calculated fields cannot be edited in the UI.

Data integrity rules: object names/custom field names should be unique enough for reporting; deleted objects are recoverable for 30 days via Recycle Bin.

Group administration delegates sub-administration; a group's statuses, layout templates, and approval processes cascade to subgroups unless overridden.

Kick-start (Excel) imports and exports move objects (projects, tasks, custom forms, users); imports require matching column headers and unique keys for updates.

API and Fusion integrations depend on stable IDs; renaming fields breaks text mode references only if the field name changes, not the display name.

Object statuses and custom statuses are configured per group; the status equivalence (e.g., which status means 'Complete') drives reporting and percent complete.

A request queue is a project with the 'Is Request Queue' setting enabled plus at least one queue topic.

Queue topic default assignee and team determine routing; routing rules can auto-select the queue topic based on custom form answers.

Issue custom forms capture intake data; fields become reportable immediately after submission.

Convert issue to project copies the issue's custom data into the project custom form when field names match.

Intake approval processes hold the request in a pending status until the approval decision is recorded.

A request converted to a project links the original issue as the resolving object, preserving history.

Planned Completion Date is calculated from planned start plus duration, adjusted by the project schedule and predecessors.

Duration Type options: Calculated Assignment, Calculated Work, Fixed Dates, and Effort Driven determine the work/duration relationship.

Predecessor lag is expressed in days; negative lag (lead) allows tasks to overlap.

Critical path tasks have zero total float; any delay there delays the project completion date.

A milestone has zero duration and zero planned hours; it appears as a diamond on the Gantt.

Project schedule (working time calendar) overrides user schedule for date math; exceptions remove working hours.

Task status Done sets percent complete to 100 unless percent complete is manually controlled.

Commitment Date is a promise date; Planned Completion Date is calculated and can differ from the commitment.

The Updates tab holds comments, approvals, and system changes; comments are reportable via note/journal objects.

Cross-project predecessors require the predecessor project's tasks to be visible to the linking user.

Percent Complete mode (Duration, Effort, Manual) sets how project-level progress aggregates child task progress.

Automatic recalculation recalculates dates when assignments, durations, or predecessors change; manual recalculation defers it.

Resource Planner compares planned hours by job role to available hours over the chosen date range and portfolio filter.

Workload Balancer shows per-user allocation with over-allocation highlighted, and supports reassignment and time-off entry.

Available hours per user = schedule working hours x FTE percentage minus time off and exceptions.

Job role allocation percentage reduces effective capacity for that role.

Scenario planning lets you save alternative planned hours per role and compare scenarios before committing.

Utilization reports compare allocated hours to available hours; values above 100 percent flag overallocation.

Text Mode filter syntax: a row is field, operator, value; prefix a group with OR:1 to change the default AND to OR.

valueexpression builds calculated columns from other fields; valuefield selects the underlying field for a prompt or filter.

Dashboards contain up to 25 sections; each section can hold one or more reports in a layout grid.

Prompt filters are configured once and can apply to multiple reports on a dashboard.

Delivery scheduling sends a report on a recurring basis; the delivery uses current data and the report's saved filters.

Sharing a report with 'Run with access rights of another user' lets viewers see data they could not otherwise access.

Velocity = story points completed per iteration, averaged over prior iterations, used to forecast capacity.

Burndown = remaining story points (or hours) per day across the iteration, plotted against the ideal line.

An iteration belongs to one Agile team; iterations for the same team cannot overlap.

Completing an iteration returns incomplete stories to the team backlog by default.

Kanban boards use status-mapped columns and may include an intake/backlog column for new work.

Story points are set per task or story; the team's estimate field drives burndown and velocity.

Proofing requires a rendered proof; document approvals can apply before a proof exists.

Proof roles: Reviewer, Approver, Author, Moderator; Guest reviewers need no Workfront license.

Automated Workflow stages advance based on the minimum decision count configured per stage.

Proof decisions: Approved, Approved with changes, Changes required, Not relevant; all recipients must decide for the proof to complete.

Uploading a new proof version retains prior comments and creates a new version record.

Approval process stages require either one approver or all approvers to decide before advancing.

Access level (Planner/Worker/Reviewer/Requester) is the ceiling; object sharing can only narrow permissions.

Layout templates control visible tabs and fields and can be assigned by user, group, job role, or as the default.

Deleted objects are recoverable from the Recycle Bin for 30 days.

Group-level custom statuses and approval processes cascade to subgroups unless overridden at the subgroup.

Kick-start imports require matching column headers and unique keys to update existing records rather than create duplicates.

Calculated custom fields are read-only in the UI and cannot be edited by users directly.

Queue topic vs. topic group: topic groups organize topics into categories; the user picks a group then a topic.

Access rule for a queue: users need at least Contribute permission on the queue project or membership in a company/group granted access.

A request's 'resolved by' object is the project created from it; conversion preserves the issue as a record.

Custom form section breaks and display logic can hide fields based on earlier answers at intake.

Approval on a queue topic routes the submitted request to approvers before work begins.

Business case stores alignment score, ROI, NPV, and risk; the Portfolio Optimizer ranks projects by these scores.

Work Required (Calculated Assignment) makes duration change when assignees or hours change.

Fixed Dates means start and completion dates are entered; work changes do not move the dates.

Effort Driven redistributes work among assignees when one is added or removed, keeping total work constant.

Constraint type overrides dependency-driven scheduling; Must Start On pins the date regardless of predecessors.

Parent task duration and dates roll up from child tasks; parent tasks should not have their own assignments.

The Gantt view shows dependencies as arrows and highlights the critical path.

Percent complete on a task can be entered directly or derived from status depending on project settings.

Approvals attached to tasks revert the task status on rejection per the approval process configuration.

Comments with @mentions notify the mentioned user and create a note record reportable in reports.

Bulk editing multiple tasks updates fields in one action; scheduling recalculates those tasks automatically if enabled.

Issues can be converted to tasks and retain their custom form data if the form is attached to tasks.

An 'In Progress' task with partial percent complete contributes a partial weighted value to project progress in Effort mode.

Resource Planner requires job role data on tasks or projects to show demand; users without roles contribute to unassigned demand.

Unassigned work in the Workload Balancer appears in the backlog section; assigning it moves it into a user's lane.

FTE on the user record scales available hours in resource planning calculations.

Time off entered in the user's schedule reduces available hours in planning and utilization views.

Portfolio and program filters scope Resource Planner demand to specific initiatives.

Overallocation is signaled by allocation above the user's available hours for the period, shown in red.

Each report type restricts available fields and objects; a Task report cannot directly show portfolio fields without a linked object path.

Text mode filter operators include eq, ne, gt, lt, contains, notcontains, isnull, and in.

Groupings and charts are configured per report; charts on a dashboard are separate report objects placed in sections.

Report prompts appear on the report or dashboard and filter results at view time.

Scheduled deliveries can be sent to users without report access only if configured with another user's access rights.

Aggregation for calculated columns requires valueexpression plus the correct aggregation attribute in text mode.

Scrum team backlog is ordered by priority; the top items are selected into the next iteration.

Story board columns map to task statuses; moving a card changes the task status.

Velocity is used to forecast how many backlog items a team can complete in future iterations.

Burndown scope changes mid-iteration appear as an upward jump in the remaining line.

Kanban boards can be configured per project or per team and support status-based columns.

Agile teams define the iteration cadence (e.g., two weeks) used by all iterations the team owns.

A basic proof workflow sends the proof to all recipients at once with no stages.

An automated workflow uses stages with deadlines and minimum decision requirements per stage.

Proof comments support markup, drawings, and attachments and are versioned with the proof.

Overall proof status is complete only when all recipients across all stages have decided.

Approval processes can be global or object-specific; a global approval can be applied to any object type it supports.

Approval decision types: Approved, Rejected, Not Yet Decided (pending); object status changes on final decision.

Object IDs are stable; display names can change without breaking API or text mode references.

Custom fields must be created and attached to a custom form before appearing on objects users can edit.

Layout templates must be assigned to users or a group/role, otherwise the default layout applies.

Deactivating a user retains their history and assignments; deleting is discouraged and recoverable for 30 days.

Group admins can manage statuses, custom forms, layout templates, and approval processes for their group only.

Kick-start exports are the standard way to move configuration between sandbox and production.