Block Done While Blockers Open for Jira: documentation

Block Done While Blockers Open is a Jira Cloud workflow validator. When someone moves a work item into a status in the Done category, it checks the item's "is blocked by" links. If a blocker is still open, Jira refuses the move and the message names the open blockers.

On this page: Add it to a workflow · Known limitations · Where the message shows up · Optional: hide Done while blockers are open · Questions

Help: support@datadelight.co. Policies: privacy policy, terms of service.

Questions

• Why does Done still appear if it will be refused? A validator runs after the click; Jira offers the transition first. The condition Optional: Hide Done While Blockers Open hides Done in the issue view and the bulk status picker, but not in the board card's Change status menu, and with it on the board, REST and Automation show Jira's generic "might not have permission" text instead of the app's message (see Optional: hide Done). We recommend it only for teams that close work in bulk.
• I moved several issues to Done in bulk and some did not move, with no reason. Jira's bulk change does not show validator messages. Open one of the issues and try the move on its own to see which blockers are open.
• An Automation rule did not close the issue. Look in Project settings → Automation → Audit log; the refused run shows Some errors, with the message beside the issue key.
• The board says "We can't move …" with a Trace and Hash. Is the app broken? No. That is how Jira draws any validator refusal on a board. The body of the flag is the app's message.
• I linked an open blocker to an issue that is already Done and nothing happened. The rule runs when an issue moves into Done, not when a link is added. The issue stays Done; moving it out of Done and back again is refused while the blocker is open.
• A parent closed while one of its sub-tasks is blocked. Only the issue's own links are checked. Sub-tasks are checked when they move to Done themselves.
• Why do some blockers have a summary in the message and others only a key? Summaries are printed only for blockers in the same project as the issue, so nothing from a project the person may not see is shown.
• Where do I find the rule again later? Jira shows no marker on the workflow diagram for transitions that carry rules, and the project's View as text dialog hides global transitions ("Any status → Done"). To find the rule again: Project settings → Workflows → Edit workflow, click the transition into Done (for a global transition, the Any badge on the Done status), then look under Validate details for Blockers must be Done first (and, if you added the condition, under Restrict transition for Optional: Hide Done While Blockers Open). Project settings → Apps does not list workflow rules.
• Which link types count? Links of type Blocks, read as "is blocked by" from the issue being moved (or any link type whose inward description is "is blocked by"). "Relates to" and other types do not count. A blocker is open until its status is in the Done category.

Where the message shows up

In bulk change and Automation, Jira does not pass the validator's message to the person. The app cannot change those screens; the opening sentence of the message is kept short so the audit log line reads on its own.

Optional: hide Done while blockers are open

The app also ships a workflow condition, Optional: Hide Done While Blockers Open. Without it, Done is offered everywhere and the validator refuses it after the click, with the app's message. The condition changes where Done is offered, not every path, and it has a cost. What was seen on a Jira Cloud site (2026-10-23) with the condition and the validator on the same transition, for an issue with an open blocker:

• Done is hidden in the issue view's status menu, in REST GET /rest/api/3/issue/{key}/transitions, and in bulk change's status picker. It comes back once every blocker is Done.
• Done is still offered in the board card's right-click Change status menu.
• Board drag: while you drag a blocked card, the Done column reads "This Task can’t be moved to this column because of workflow configurations or permissions." Dropping it there does nothing: no message and no log line.
• In bulk change, one blocked issue removes Done for the whole selection. Jira offers only the statuses that every selected issue shares ("Only showing statuses shared across the selected work items."), so the unblocked issues in the selection cannot go to Done either. Deselect the blocked issues to close the rest.
• The board, REST POST …/transitions and Automation lose the app's message. Jira refuses the move itself, before the validator runs, and shows its own text. As recorded on the test site: on the board, We can't move Task BCW-9 with Can't move (BCW-9). You might not have permission, or the work item is missing required information. If you keep having this problem, contact your Jira Administrator.; from REST, HTTP 400 with {"errorMessages":["Can't move (BCW-14). You might not have permission, or the work item is missing required information. If you keep having this problem, contact your Jira Administrator."],"errors":{}}; in the Automation audit log, Unable to transition your issue to the selected status: BCW-10 (Backlog - 10032).
• The app writes no log line for those attempts, because its code never runs for them.
• Where Done is hidden, nothing tells the person why. The issue's View workflow dialog even lists Done under "This work item can be moved to", because that dialog does not apply conditions.

We recommend the condition only for teams that close work in bulk, where hiding Done from the picker is worth the generic message elsewhere. Everyone else gets clearer refusals from the validator alone.

To add it: in the workflow editor, open the transition into Done and choose Add rule → Restrict transition → Optional: Hide Done While Blockers Open; there is nothing to configure; then Update workflow. Add rule lists this condition above the validator (Jira puts Restrict transition rules first, in search results and in the app's Marketplace rules entry); its description says it is optional and needs Blockers must be Done first too. The validator stays under Validate details (as Blockers must be Done first). To remove the condition, use the card's ⋯ → Delete rule, then Update workflow. Keep the validator: a condition is evaluated as the person viewing the issue, so a blocker they cannot see does not hide Done, whereas the validator reads as the app and still refuses. The condition is a Jira expression in manifest.yml; it is a Forge preview module (jira:workflowCondition). Forge gives a condition no way to carry a message, and no app module can change what the board card's status menu offers.

Add it to a workflow

Company-managed project (the workflow editor as Jira Cloud showed it on 2026-10-23):

1. Project settings → Workflows → Edit workflow (or Settings → Issues → Workflows as a Jira admin).
2. Click the transition that leads into your Done status (for example Done; for a global transition, the Any status → Done row).
3. Choose Add rule and type blocker in the search box. Searching is quicker than browsing: the unfiltered list puts this rule below the fold.
4. Choose Blockers must be Done first (its description starts "The main rule: add this one.") and Select. There is nothing to configure. It appears under Validate details.
5. Update workflow.

Team-managed project: the app declares team-managed support, but no walk has tried it yet. The path should be Project settings → Issue types → (type) → Edit workflow, then the same Add rule steps.

The validator refuses only transitions whose target status is in the Done category, so it is harmless on other transitions.

Known limitations

What the app does not do, in plain words. Each item was seen on a Jira Cloud site, except the last list.

• Bulk change shows no reason. The blocked issues stay put and Jira says only "n/n items not updated". Try the move on one issue to see the message.
• Automation shows the reason only in the audit log. The person who ran the rule sees "Your automation is in progress" and nothing else.
• Long lists are shortened. The message is kept to about 200 characters so Jira's five-line flag shows all of it. It names at most five blockers, then "and N more", and cuts long summaries short.
• On the board, a long message can push Jira's Copy / Hash / Trace footer out of view. The message itself stays whole.
• The optional condition is listed first in Add rule, and that order cannot be changed. Jira puts Restrict transition rules above Validate details rules. Its name starts "Optional:" for that reason.
• The optional condition costs the message on the board, REST and Automation (Jira shows its generic "You might not have permission" text there) and ignores blockers the viewer cannot see. See Optional: hide Done.
• Only the issue's own links count. Sub-tasks and parents are not checked, and only links of type Blocks (read as "is blocked by").
• Nothing happens when a blocker is added to an issue that is already Done. The rule runs only when an issue moves into Done.
• Only two-issue loops are named. If A blocks B and B blocks A, the message says so. Longer loops cannot be seen from one issue's links.
• English only.

Not yet tried on a site: team-managed projects, the Jira mobile app, a second user who cannot see a blocker, and a deleted blocker.