The Shared Workflow That Broke Two Teams
A company runs one Jira Software project (Company-managed) for two teams: Platform and Billing. Both teams share a single workflow called "Software Simplified" with statuses To Do, In Progress, In Review, Done. Platform wants a mandatory "Reviewed By" field before entering Done. Billing wants no such requirement and also wants a new status "Awaiting Customer". There are 480 open issues in the project, 210 belonging to Billing. The admin edits the shared workflow to add the validator and the new status. Within a day, Billing users report that they can no longer move issues to Done because the validator fires, and their boards show the new column but issues do not transition correctly. The project has 3 boards and 6 automation rules referencing status names.
1. Diagnose why Billing's transitions broke and explain the structural mistake the admin made.
Read the worked answer
The root cause is that a single workflow was shared across two teams with divergent process requirements. In Jira, a workflow is a reusable scheme component; editing it changes behavior for every project and issue type that uses the scheme. When the admin added a required-field validator to the "Done" transition, that validator applies to all issues in the workflow, including Billing's 210 issues. Because Billing users have no "Reviewed By" value and the field is likely not on their screens, the transition is blocked. This is not a bug; it is the expected consequence of shared configuration.
The structural mistake was treating divergent requirements as a single-process problem. The correct pattern is to separate workflows first, then attach them via a workflow scheme, either by issue type or by project. Here, because both teams work in the same project, issue-type-based separation is the practical lever: create distinct issue types (or use existing ones) so Platform and Billing issues can map to different workflows within one scheme.
The new status "Awaiting Customer" compounds the problem because statuses are global objects, but the transition and screen configuration must be added deliberately. Boards relying on status categories (To Do / In Progress / Done) may still render, but automation rules that reference literal status names will silently stop matching if the name or presence changed.
2. Propose a remediation plan that preserves both teams' requirements with minimal disruption, and state the risks of each step.
Read the worked answer
Step 1: Freeze further workflow edits and communicate. Confirm which issues are Billing vs Platform using a saved filter (e.g., by component or a custom field), so the 210 / 270 split is verifiable before any migration.
Step 2: Split the workflows. Duplicate the current workflow into "Platform Workflow" and "Billing Workflow". On the Platform copy, add the "Reviewed By" validator and ensure the field is on the transition screen and required at the field-configuration level if appropriate. On the Billing copy, add the "Awaiting Customer" status with its own transitions and remove the validator.
Step 3: Update the workflow scheme. Map issue types to the appropriate workflow. If both teams use the same issue type today, introduce or repurpose a distinguishing issue type, or accept a project split. Changing issue types on existing issues triggers a workflow migration for those issues; Jira will prompt for status mapping where the new workflow lacks a matching status. Map carefully so no issue lands in an unintended status.
Step 4: Fix dependent configuration. Audit the 6 automation rules and 3 boards. Replace literal status-name conditions with status-category conditions where semantics allow, and add explicit handling for "Awaiting Customer" (e.g., map it to the In Progress category so it does not appear as Done).
Step 5: Validate in a staging or sandbox copy, then apply in a low-traffic window. Risks: workflow migration can move issues to wrong statuses if mappings are wrong; automation rules may double-fire during migration; boards may briefly show incorrect columns. Keep a rollback plan: export the scheme configuration and record the pre-change mappings.
3. A stakeholder asks why the admin cannot simply make the "Reviewed By" validator conditional on team membership. Evaluate that suggestion.
Read the worked answer
It is technically possible but architecturally weak. Jira validators run in the context of the transition, and conditional logic can be built with a scripted validator or a condition on the transition that checks group membership, project role, or a custom field value. So a conditional validator that only fires for Platform users is feasible.
However, this concentrates two teams' process rules into one workflow and one validator, which creates several problems. First, the logic becomes invisible to most administrators; a future edit can break it without obvious symptoms. Second, group membership is a poor proxy for process ownership: people change teams, and shared accounts or automation users may not belong to the expected group. Third, it makes testing harder because the same transition behaves differently for different actors, so a single test pass does not prove correctness.
The better judgement is to separate the process where the requirements genuinely differ, and reserve conditional logic for narrow exceptions (for example, a single issue type that occasionally needs an expedited path). If conditional logic is used, document it, name the validator clearly, and add an automation test that exercises both branches. The exam-style lesson: prefer configuration that reflects the real process boundary over clever conditionals that hide it.