No More Hidden Dependencies: Auto-Flagging Blocked and Blocking Work with Jira Automation

[#1]

"Blocks" and "is blocked by" are two of the most useful link types in Jira — used well, they let you model real dependencies between work items. They also share one big flaw: they're invisible until you're already looking at the item. Nothing shows up on a board, backlog, or filter to say "this can't move forward yet" or "three other items are waiting on this one." Teams either end up training everyone to check the Links panel on every card (doesn't scale) or bolt on a marketplace app just to surface something Jira already knows.

I wanted a way to make blocking relationships visible at a glance, using only native Jira Automation — no app, no added cost, and no manual upkeep. Here's the approach I landed on, generalized so you can drop it into your own instance.

The idea, in one sentence

When a "Blocks" link is created, prefix the blocking item's summary with [BLOCKER] and the blocked item's summary with [BLOCKED] (plus a Dependent label for filtering) — then automatically remove those tags the moment they stop being true, whether that's because the link is deleted or because the dependency resolves itself.

Example: Link work item A ("Build API endpoint") as a blocker of work item B ("Build UI that calls the endpoint"). After the link is created:

• A's summary becomes: [BLOCKER] Build API endpoint
• B's summary becomes: [BLOCKED] Build UI that calls the endpoint (and B picks up a Dependent label)

Anyone scanning the backlog or board now sees the dependency without opening either item. When A is completed, or someone removes the link, both tags disappear on their own — no one has to remember to clean them up.

Three rules, one lifecycle

Rule	Trigger	Job
Set	A Blocks link is added	Tag both sides of the new relationship
Clear on Unlink	A Blocks link is deleted	Untag both sides, if nothing else still justifies the tag
Clear on Resolve	An item transitions to a "finished" status	Untag itself, and cascade the cleanup to anything still linked to it

Rule 1 — Set the flags when a link is created

Trigger: Issue Link Added — link type Blocks Trigger condition: the triggering item's status isn't already closed (I exclude Done and Won't Do — use whatever your closed statuses are)

Logic:

1. If the triggering (blocking) item's summary doesn't already contain [BLOCKER], and it isn't in a Done status category → set summary to [BLOCKER] {{issue.Summary}}
2. Branch to the destination item (the one being blocked): if its summary doesn't already contain [BLOCKED], and it isn't in a Done status category → set summary to [BLOCKED] {{issue.Summary}} and add the label Dependent

I also added a simple space-exclusion condition here — one area of my instance (a roadmap-style space) doesn't benefit from per-item summary prefixes, so I filtered it out of both branches. Easy to bolt on if you have something similar.

Rule 2 — Clear the flags when a link is removed

Trigger: Issue Link Deleted — link type Blocks

Logic:

1. On the item that just lost a Blocks relationship: if its summary still contains [BLOCKER], and it no longer has any remaining Blocks links → strip the [BLOCKER] prefix
2. Branch to the other side of the deleted link: if its summary contains [BLOCKED], and it no longer has any remaining is blocked by links → strip [BLOCKED] and remove the Dependent label

The important detail is "any remaining links," not "this specific link." If an item has three separate blockers and you remove one, it should stay tagged [BLOCKED] until all three are gone. Checking for the presence of any remaining link of that type — rather than just reacting to the one that was deleted — is what makes this safe for many-to-many blocking relationships.

One known limitation: if someone deletes the linked item itself rather than just removing the link, this rule can throw an error, even though the tag cleanup on the surviving item still completes correctly. I haven't found a clean way around it — Jira Automation doesn't currently offer a way to check "does the other end of this link still exist" — so I've accepted it as a cosmetic error in the audit log and moved on.

Rule 3 — Clear the flags when the dependency resolves itself

This one took the most iteration, because "the dependency resolved itself" has to account for every other active link that item might still have.

Trigger: Issue Transitioned Trigger condition (JQL): statusCategory = Done OR status = Verification — swap in whatever combination of statuses you treat as "finished" (I also treat a pre-close verification step the same as Done)

Logic:

1. Store the transitioning item's key in a variable, e.g. SourceIssueKey = {{issue.key}} (needed below — see the first gotcha)
2. Self-cleanup: if this item's own summary still carries [BLOCKER], strip it — a finished item can't meaningfully block anything
3. Self-cleanup: if this item's own summary still carries [BLOCKED], strip it and remove the Dependent label
4. Cascade downstream — branch to every item this one blocks. For each, check whether it has any other active blocker besides the one that just resolved:

   issue in linkedIssues({{issue.key}}, "is blocked by")AND statusCategory != Done AND status != VerificationAND Key != {{SourceIssueKey}}
   

   If none match, and the item is still tagged [BLOCKED], clear the tag and the label.
5. Cascade upstream — branch to every item that blocks this one. For each, check whether it still blocks any other active item:

   issue in linkedIssues({{issue.key}}, "blocks")AND statusCategory != Done AND status != VerificationAND Key != {{SourceIssueKey}}
   

   If none match, and the item is still tagged [BLOCKER], clear the tag.

A log action stating the source key and current status right after step 1 is optional, but it's cheap, and it pays for itself the first time you're staring at the automation audit log trying to figure out why a cascade branch didn't fire.

Two gotchas worth knowing before you build this

1. Exclude the source issue explicitly — don't rely on re-checking its status. Steps 4 and 5 both filter out the just-transitioned item by key rather than trusting a fresh JQL check of its status. That's deliberate. The condition runs moments after the transition, and JQL here is served from Jira's search index rather than the live field value — there's a small but real propagation delay. Without the Key != {{SourceIssueKey}} filter, the source item can briefly still show up as an "active blocker" in that search, and the cascade cleanup would incorrectly skip clearing the other item's tag. Capturing the key in a variable at the top of the rule and filtering it out downstream sidesteps the whole race condition. It's a good pattern to remember any time an automation rule needs to reason about the current item's post-change state from inside a related-issue JQL check.

2. Removing a link is not the same as deleting an issue. As noted above, deleting a linked item outright can produce a harmless but noisy error on the unlink rule. Worth knowing before you assume a red mark in the audit log means the tags are wrong — check the actual summary before digging further.

Design decisions that made this durable

• One rule per trigger event, not one giant rule. Each of the three is independently testable, and a failure in one doesn't take the others down.
• "Any remaining link," not "this link." Checking for the presence of other active relationships — rather than reacting only to the specific link that changed — is what makes this safe when an item has multiple blockers or blocks multiple items.
• Skip already-closed items up front. Status checks on both the trigger and the conditions mean the rules never touch historical, closed work, and never make unnecessary field edits.
• Turn off "allow other rules to trigger" on all three rules. These rules edit the Summary field and a label; if you have other automation watching for summary or label changes, this stops an unintended cascade into rules that have nothing to do with this system.
• A label alongside the visual prefix. The bracketed summary tag is what people see on a board or backlog card; the label is what lets you build a saved filter or dashboard gadget (labels = Dependent) without parsing summary text.
• Optional space exclusions. Not every part of an instance benefits from this — I excluded one roadmap-style space where per-item summary prefixes weren't useful, and left that as a standard condition anyone can reuse.

Adapting this to your own instance

• Swap Blocks / is blocked by for whatever link type names you actually use if you've renamed or added custom link types
• Redefine "finished" for the resolve rule — Done category alone, or additional statuses like a pre-close QA/verification step
• Decide whether to scope all three rules to specific spaces, or run them site-wide
• Pick your own tag text and label name — [BLOCKER] / [BLOCKED] and Dependent are just what I landed on
• Decide whether these summary/label edits should notify watchers or run silently — I left notifications on, since "this item just became blocked" is meaningful context, but it's a one-click change if your teams find it noisy

Wrapping up

The whole thing runs entirely on native Jira Cloud Automation — no marketplace app, no added license cost, and it fixes itself as work moves instead of relying on someone remembering to update a flag. If you build a version of this, I'd love to hear what you changed. And if you find an edge case I haven't — multi-hop blocking chains three or more levels deep are the one I'm still keeping an eye on — drop it in the comments.

[Anne Saunders]

This is very interesting. Thanks for sharing!

I use a global self transition to "pin" blocked items in place on the board, then a card color to make it obvious that they're blocked, but I'm still not showing dependencies outside the timeline. 

[Shawn Stevens]

Interesting. I'm not sure why but I have never been a big fan of adding things to the summary after the work item was created. It is interesting to see the process you went through and to completely do it natively is awesome. We wouldn't do well with this because we don't have enough consistent use of linked types and governance, so it ends up being almost a random selection. We are definitely not using Blocks/Is Blocked by well. I will need to take a closer look at this but thank you for the detailed write up. Well done. 

@Anne Saunders That is interesting about the global self transition and pinning it on the board. Are you using the native Flag functionality, since that colors the card by default and is visual or are you also using the linked types. 

[Anne Saunders]

@Shawn Stevens I'm not using Flags, but the Card Colors feature in Board configuration with a JQL Query to catch work items that are blocked.

Since I built it a couple (ok, few) years before they added commenting to adding a flag, my Block transition throws up a screen with fields to record the blocking linked issue and a comment.