One Workflow, Three Projects, Four Change Requests

Request	Verdict
Add Awaiting Vendor, Bugs only	Doable, but only via a separate workflow for SUP/Bug
Reporter-only back-transition	Doable, scoped to SUP
Global All → Closed	Refuse as stated - see third task
Delete In Review	Refuse

Why the status needs a copy of the workflow. Delivery Workflow is referenced by three schemes and three issue types. Publishing an edit to it changes ALPHA, BETA and SUP simultaneously - which directly violates the mid-release constraint. Copy Delivery Workflow to SUP Bug Workflow, add Awaiting Vendor between In Progress and In Review, publish, then change only SUP's workflow scheme mapping for the Bug issue type. ALPHA, BETA and SUP's Story and Task keep the original workflow untouched.

Why deleting In Review is refused. A status cannot be removed while any workflow references it. Removing it means migrating every issue sitting in that status across all three schemes and editing every workflow that uses it. SUP not using it is irrelevant to ALPHA's process; the request needs all three project owners, not just SUP.

Confirm the plan with a test: publish the copy, attach it to a scratch project, and transition a bug through every path before touching SUP.

Attach a condition to the transition, not to the status.

• In SUP Bug Workflow, open the Awaiting Vendor → In Progress transition and add a condition: Only the reporter. Conditions hide the transition from everyone else; a validator would let them click and then fail, which produces support tickets of its own.
• Add a transition screen with a comment field so the rework reason is captured and reportable.

Consequences to raise before publishing:

1. The reporter can leave. If the reporter is deactivated or moves team, nobody can move the issue back except by editing the workflow. Widen the condition to include group jira-internal as an escape hatch, or document the admin workaround.
2. Automation obeys conditions. A rule that transitions this issue runs as its configured actor. If that actor is not the reporter and is not in the allowed group, the transition fails and - depending on action order - earlier actions may already have run. Check every rule touching SUP bugs before go-live.
3. You are creating a new metric whether you want one or not. Time in Awaiting Vendor becomes measurable the moment the status exists; capture a baseline and add it to a dashboard, or the first report will show a spike that is purely an artefact of the change.

An All transition is a workflow bypass wearing the costume of a convenience.

• An All transition applies from every status, including statuses whose entry gates exist deliberately. One click lets an issue skip In Review, approvals, or required-field checks, and the audit trail records it as a normal transition. Cycle-time and review-coverage reports become quietly wrong, and nobody notices until an audit.
• Under the constraint that ALPHA and BETA must not change, this is doubly wrong: adding All → Closed to the shared workflow would alter their behaviour too.

What to approve instead:

• Explicit transitions to Closed from the statuses that legitimately close - e.g. In Review → Closed and Awaiting Vendor → Closed - each with its own screen and validator (resolution, root cause). Each path stays auditable.
• If a bulk-close capability is genuinely needed, add the All → Closed transition to SUP Bug Workflow only, with a validator enforcing resolution and a condition limiting it to group jira-internal. Document that it exists for cleanup, not for daily flow.
• Do the cleanup as a JQL bulk change instead. 1,200 open bugs is a one-off data problem, not a permanent workflow requirement. Bulk change leaves a single auditable event and requires no workflow change at all.

Test on the scratch project first: filter the open bugs and see how many would jump status under an All transition before promising anything.