The Proof That Sat in Stage 1 for a Week
Cascade Health's regulatory team routes every patient-facing PDF through a two-stage automated workflow in Workfront proofing. Stage 1 has three participants: the marketing lead as Approver, the legal reviewer as Reviewer, and the compliance officer as Approver, with the stage configured so that all decisions are required. Stage 2 has a single participant, the CMO, as Approver, with a two-day deadline. Twice this month a proof sat in Stage 1 for over a week. In both cases the legal reviewer had marked Changes required and the marketing lead had approved; the compliance officer never opened the proof, because the email address on the workflow contained a typo. The proof had also been created with the require-login setting enabled. After a revised PDF was uploaded as Version 2, the workflow started again at Stage 1 and the CMO's earlier approval no longer appeared where the team expected it.
1. Explain why Stage 1 stalled and separate the configuration choices from the operational failure.
Read the worked answer
Four distinct causes, and conflating them will produce the wrong fix.
- 'All decisions required' is a gate, not a preference. The stage cannot complete until every participant on it has recorded a decision. One silent participant holds the whole stage - by design.
- A wrong email address makes a participant non-existent in practice. The compliance officer is on the workflow and cannot act, so the gate can never close. Nothing in Workfront escalates that; the stage simply waits.
- Require login blocks the invited-by-email path. If any participant is a guest without a Workfront account, require-login can prevent them opening the proof at all, converting an availability problem into an invisible one.
- No deadline on Stage 1. Stage 2 had a two-day deadline; Stage 1 had none, so the stage with the most participants had the least time pressure.
Separately note the role design: the legal reviewer is a Reviewer, not an Approver, yet their 'Changes required' decision arguably should have blocked - the stage setting, not the role, decides that.
The failure is operational, but the configuration made it undetectable for a week.
2. Recommend the workflow changes you would make, and explain the trade-off in each.
Read the worked answer
Set a deadline on every stage, not just the last one - Stage 1 should have a deadline shorter than Stage 2, because more people are being asked. Trade-off: deadlines create escalation noise on genuinely blocked reviews, so pair them with reminders rather than punitive automation.
Match the gate to the risk. 'All decisions required' is defensible for regulatory sign-off, so keep it - but only for the participants who must genuinely each sign. If the CMO's approval is the binding one, consider whether Stage 1 needs two approvers or one approver plus advisory reviewers whose decisions inform rather than gate. Trade-off: fewer gates mean faster throughput and weaker audit trail; in a regulated context, do not trade away the audit trail.
Validate addresses at intake. Add a step (and, if available, a check) to verify participant emails before the proof is shared, and make the sender confirm the participant list. Trade-off: an extra 30 seconds per proof against a week of silence.
Resolve the require-login decision deliberately. If guests must review, ensure they can access via the emailed link; if security policy demands login, then every participant needs an account and the workflow owner must confirm that before sending. Trade-off: this is a policy question disguised as a checkbox - escalate it rather than toggling it per proof.
Add a stalled-proofs report on the regulatory dashboard: proofs with an open stage past its deadline, and stages with participants who have not viewed. Visibility is the control that was missing.
3. The team is surprised that Version 2 restarted the workflow and that the CMO's earlier approval was no longer where they expected it. What should they understand about versioning, and what practice would you put in place?
Read the worked answer
Approvals attach to a version, not to a document in perpetuity. That is correct behaviour: the CMO approved a specific PDF, and Version 2 is a different PDF. Carrying an approval forward automatically would be an audit failure, not a convenience.
What the team needs to know:
- Decisions live on the version they were made against. The summary distinguishes versions; approving v1 does not approve v2. Review the proof history by version before declaring that an approval 'disappeared.'
- A new upload can re-trigger the workflow. When adding a version the uploader chooses whether to apply a workflow; defaulting to the full automated workflow re-runs every stage, including the CMO's. That was a choice made at upload, even if it felt automatic.
- Restarting Stage 1 is often correct and sometimes waste. If the change is a typo fix, re-running legal and compliance is expensive; if the change touches regulated content, skipping them is indefensible.
Practice to adopt:
- A written version policy per document class - which changes require a full re-review, which require only the approver of record.
- A change note on every version describing what changed, so reviewers can decide scope quickly.
- Tell the approvers when a new version resets their decision, ideally in the version's message to reviewers, so nobody assumes a prior sign-off carries.
- Keep the workflow as short as the policy allows - every extra stage multiplies the cost of each re-review round.