Teams use workflow rules to make sure a work item cannot move forward until it has been approved. Today the app offers only one such rule: a workflow condition that requires picking a single, specific approval definition. This has two gaps:

1. When the approval definition is chosen dynamically (different approval processes for different work items, e.g. per region or per request type), the admin cannot know upfront which definition to select in the rule, so no rule fits.

2. When several approvals run on one work item, there is no way to require that all of them are completed before the work item can change status.

On top of that, the existing rule is a condition: the transition silently disappears from the UI. Users do not understand why they cannot move the work item, which generates confusion and support questions.

Proposed scope

1. A new workflow validator: when a user tries to transition a work item that still requires approval, the transition is rejected with a clear, human-readable message explaining why (approval still pending, or the required approval is missing).

2. A new rule mode, available in both the validator and the existing condition: "all approvals completed". It works regardless of which approval definition was started and covers work items with multiple approvals:

   • the transition is blocked while any approval on the work item is pending (IN_PROGRESS),

   • an approval is treated as satisfied once it is no longer pending; only pending approvals block the transition,

   • an additional option "Require at least one approved approval" (enabled by default) decides how the rule treats work items that have no approved approval: enabled = the transition is blocked unless at least one approval was approved (so a work item whose only approval was rejected stays blocked, and a work item with no approvals at all stays blocked); disabled = work items with no pending approval can transition freely regardless of whether any approval was approved or rejected. This supports processes where an approval is started only for some work items.

3. The current mode (approved with a specific definition) stays available in both rule types.

4. These rules apply to manual and automated transitions alike (REST API, Jira Automation, the app's own automatic status change), with no exemption and no deferred retry. Consequence for configuration: an automatic status change must be triggered from the approval's Success step. Triggered earlier, from an automation step inside the flow, from the Rejection step, or on work item creation, it is rejected, because the work item has no approved approval at that moment.

5. Both rules are available in all project types: company-managed and team-managed, Jira Software and Jira Service Management.

Acceptance criteria

• An admin can add the validator or the condition to any workflow transition and choose one of two modes: "approved with a specific definition" or "all approvals completed", the latter with the "Require at least one approved approval" option.

• In "all approvals completed" mode, the transition is blocked while any approval on the work item is pending, and allowed once no approval is pending; the "Require at least one approved approval" setting decides whether a work item with no approved approval (none started, or only rejected ones) is additionally blocked.

• When the validator blocks a manual transition, the user sees a message explaining why; transitions triggered via API or automation are rejected as well.

• Automated transitions are evaluated against the same rule as manual ones: a status change triggered from the approval's Success step passes, one triggered before the approval reaches its final state is rejected.

• A rejected automatic status change records the reason on the approval's automation step and is not retried.

• Rules can be configured in company-managed and team-managed projects, in both Jira Software and JSM.

• Existing rule configurations keep working unchanged after the upgrade.