Collaboration, Proofing, and Approvals
Agile and Work Management (Boards, Backlog, Iterations)
Core concepts
Agile work in Workfront is organized around teams. Each team has Agile settings that determine whether it runs Kanban or Scrum. The team's statuses map to board columns, so a card moves when its status changes - not the other way round.
The Backlog holds stories, tasks, and issues not yet scheduled. In Scrum, work is pulled into an iteration with start and end dates; the story board then tracks cards through columns, and story points feed the burndown. Kanban boards support WIP limits per column and an intake column for new items.
Cards are connected to real work items: completing a card completes the task or issue, and vice versa.
Traps
- Board columns come from team statuses, not project statuses; a status missing from the team's list means a missing column.
- A work item appears on one team's board at a time - moving teams moves the card.
- Iterations have fixed dates; unfinished stories must be moved to the next iteration or back to the backlog.
- Story points are a separate field from planned hours and are not interchangeable.
- The burndown reflects remaining points over the iteration, not hours logged.
Worked example
A story sits in the backlog with 5 points. The team starts an iteration; the story is moved into it and appears on the story board. When the assignee changes the task status to In Progress, the card moves from the New column to the In Progress column automatically because those statuses are mapped to those columns.
Collaboration, Proofing, and Approvals
Core concepts
Collaboration centers on the Updates tab: comments, replies, tagging users, likes, and system updates, all searchable and often filterable to show only comments. Mentions trigger notifications; private updates restrict visibility.
Proofing is a separate review workflow on documents and web content. Generating a proof opens a review link where participants mark up the file and record a decision (Approved, Approved with changes, Changes needed, Not relevant). Proof roles - Reviewer, Approver, Reviewer and Approver, Author - determine what a person can do. Stages sequence reviewers; a stage can be set to require only one decision.
Approval processes exist for projects, tasks, issues, documents, timesheets, and proofs. They can be global, group-level, or one-time, contain multiple stages, and support delegation. Document approvals (native) and proof approvals are distinct objects.
Traps
- A proof approval and a document approval are not the same; a proof decision does not always update the document's approval status.
- Approval stages run in order; the next stage only starts when the prior stage resolves per its rule.
- Auto-approve and auto-reject settings on an approval process can short-circuit a stage.
- Global approval processes must be attached to something to take effect.
- Tagging someone in an update notifies them but does not grant them access to the object.
Rule of thumb
Ask: what is being approved (object), who must decide (role or approver), and how many stages. Answers come from the approval process, not from sharing settings.