Task completion based on proof decision -- Version control?

Hi ​@Kasey-Gagne , What I’ve seen in most cases, the cleanest and most scalable approach is to keep everything within the same task and use Workfront Proof’s versioning capabilities. Instead of creating new tasks for each round (R1, R2, etc.), teams typically upload new versions of the proof to the same task. This allows all feedback, decisions, and version history to remain in one place, making it much easier to manage and audit, while older versions are automatically locked.

From an automation perspective, task completion can be driven based on proof decisions (for example, Approved → complete task, Changes Required → move to the next step like another design round). This works best when the proof is attached at the task level, and routing can be handled either through native dependencies or more advanced logic using Fusion. While creating separate tasks for each round can provide clearer separation, it often leads to cluttered projects and added complexity in reporting and automation. As a result, most teams prefer a single-task approach combined with versioning and workflow automation to keep the process structured and traceable.

I’d suggest checking these documentations for automated proof workflows and Workfront’s versioning system. 

Hi ​@Kasey-Gagne 
The approach I would use is:
- One **Design** task + one **Creative Review** task per stage in your template
- Designer uploads to the Design task → marks complete
- Proof is created on the **Creative Review task** (not the project level — this is critical for decision-based automation to work)
- Automated Proof Workflow (APW) routes it to the right reviewers
- Each revision round = a **new proof version** uploaded to the same Creative Review task

This keeps all rounds, feedback, and decisions in one auditable place. Creating new tasks per round leads to clutter, broken predecessors, and reporting nightmares.

---

**How the automation actually fires**

Workfront's native proof decision settings (under Project Preferences) can update a deliverable status when a proof decision changes — but it's limited. For true task completion logic, you need **Fusion or automated workflow rules**:

- **Approved** → Fusion detects the decision, marks Creative Review task Complete, predecessor logic unlocks the next stage
- **Changes Required** → Fusion keeps the task open, notifies the designer to upload a new version — which becomes v2 of the proof on the same task

The loop resets naturally with each new version upload. No new tasks needed.

---

**If you truly need separate R1/R2 tasks**

Fusion can dynamically create successor tasks when a "Changes Required" decision fires — but this adds significant complexity to your scenario and your project template. Only go this route if your reporting or resourcing requires that granularity.

For most teams, version-based cycling on a single task is the right call. Simpler to build, simpler to maintain, and Workfront's native versioning handles the audit trail for you.

technically yes, the proof can live on the Design task and the automation will still fire. But there's a reporting tradeoff: your Design task stays "In Progress" during the entire review cycle, which muddies your project status and timeline reporting.

The better fix for the UX concern is to assign your designers to both the Design task and the Creative Review task. That way the Review task shows up in their My Work queue and uploading there feels completely natural, it's just another task they own.

If you want to go a step further, Fusion can bridge the gap entirely: trigger when the designer marks the Design task Complete → automatically generate the proof on the Creative Review task from the uploaded document. Designers just upload to their task and mark done, Fusion does the handoff. Zero retraining needed.