I want to create an automation rule so that Subtask can't be close until link issue are not closed

[jyoti_suryan]

I want to create a Jira automation rule to prevent a sub-task from being closed until all of its linked issues are in the Done/Closed status.

Requirement:

• When a user transitions a sub-task to Done/Closed, the automation should check all linked issues.
• If any linked issue is not in the 'Done' status category, the sub-task should not be allowed to close (or should be automatically transitioned back to its previous status with an appropriate comment).
• The sub-task should only be allowed to close once all linked issues are in the Done/Closed status.

Could you please advise on the best way to configure this using Jira Automation? If this is not possible with automation alone, please let us know whether a workflow validator or another solution is required.

[Martin Runge]

Hi @jyoti_suryan

While you can technically use Jira Automation to achieve this, I would prefer to use a Workflow Validator or Condition instead if you have the needed capabilities. Jira's native workflow validators cannot do this, so you need marketplace apps like JMWE or JWT.

Jira Automation rules run asynchronously, firing after the user clicks the button and transitions the sub-task to "Done." If the rule finds the closure invalid, it reopens the issue and writes a comment explaining the status change, resulting in a poor user experience, unnecessary notifications, audit logs, and the consumption of automation limits. Depending on the user experience, you could use a workflow condition to hide the transition completely or use a workflow validator to explain to the user what is wrong.

Remember, a sub-task is strictly locked to its single parent issue, but it can have multiple independent relationships via issue links from different projects. That is why I prefer your requirement not be in the 'Done' status category, since there could be different "Done" statuses.

Your automation could look like this:

• Trigger: transitioned to Done.
• Lookup issues action with JQL: issue in linkedIssues("{{triggerIssue.key}}", "blocks") AND resolution is EMPTY
  (drop the link-type argument if you want all links).
• Smart values condition: {{lookupIssues.size|0}} greater than 0.
• Comment, then transition back.

[jyoti_suryan]

I have created the automation rule as you said, but it's not getting triggered. I have attached a screenshot for reference 

[Christos Markoulatos -Relational-]

Hi @jyoti_suryan 

The behavior you are describing is a known Jira limitation, not a missing setting. Jira Automation runs after a transition completes, so it cannot truly block a sub-task from closing, and Jira's native conditions and validators can only check sub-tasks and the parent, never linked issues. Your options are a soft automation workaround (trigger on the transition to Done, check the linked issues, and transition the sub-task back with a comment if any are still open) or a real block using a Marketplace app validator such as JMWE's Linked Issues Status Condition or a ScriptRunner scripted validator on the Close transition. If you want to stay mostly native, create a "Can be closed" checkbox, have automation tick it only when all linked issues are resolved, then add a workflow validator that checks that field. I would raise a support ticket only to confirm your automation execution limits before building a multi project rule.

Hope this helps!

Helpful links:
https://support.atlassian.com/jira/kb/how-to-automatically-transition-an-issue-to-a-closed-status-when-all-linked-issues-are-closed/
https://community.atlassian.com/forums/Jira-Service-Management/How-can-I-block-an-issue-from-being-closed-until-its-linked/qaq-p/2973798
https://jira.atlassian.com/browse/JRACLOUD-43369

[Maya Lindholm]

Hi Jyoti,

I agree with the validator approach if you need to truly stop the transition before it happens. Automation runs after the transition, so it cannot really prevent the user from clicking Done. It can only detect the problem afterwards and move the sub-task back.

If that fallback behavior is acceptable, the automation shape would be:

1. Trigger: Issue transitioned to Done/Closed

2. Condition: Issue type equals Sub-task

3. Lookup issues with JQL for linked issues that are not done

4. Condition: Lookup issues count is greater than 0

5. Action: Transition the sub-task back to the previous/open status

6. Action: Add a comment explaining which linked issues are still open

The key part is the lookup JQL. For example, start from something like:

issue in linkedIssues({{issue.key}}) AND statusCategory != Done

Then test it with your actual link types and statuses, because some sites use several Done/Closed statuses.

For a clean user experience, a workflow validator from a Marketplace workflow app is usually better because the user gets blocked immediately with a clear message. The automation version is workable, but it is more of a correction-after-the-fact rule.

[Germán Morales _ Hiera]

Hi @jyoti_suryan , straight to your closing question: automation alone can't truly prevent the close. Rules run after the transition completes, so the most a rule can do is let the sub-task reach Done and then bounce it back; it can't stop the click itself. If that reactive behaviour is acceptable, the rule is:

• Trigger: Issue transitioned, into your Done or Closed status.
• Condition: a Related issues condition over the linked issues requiring their status category to be Done, or branch on the linked issues and check each one.
• Action: when any linked issue is still open, transition the sub-task back to its previous status and post a comment explaining why.

For a hard block that stops the transition before it happens you need a validator on the Done transition, not automation. Jira's built-in validators don't cover linked-issue status, so that part takes a workflow-validator app from the Atlassian Marketplace, or ScriptRunner if you are on Data Center. Atlassian's write-up of the linked-issue automation pattern is here.

[jyoti_suryan]

I am using Jira Premium. any option in this 

[Germán Morales _ Hiera]

Premium doesn't change the core of it, @jyoti_suryan : no Jira plan ships a native validator that blocks a transition based on linked-issue status, so a true hard block still needs a Marketplace workflow-validator app or ScriptRunner. That part is identical on Standard and Premium.

Where Premium helps is running the reactive rule without limit worries. Single-project rules are unlimited on every plan, and the multi-project or global rule you'd need when linked issues sit in other projects gets 1,000 runs per licensed user a month, pooled across the site, per Atlassian's automation service limits. So the bounce-back rule runs fine for you; it just stays a revert, not a true block.

[jyoti_suryan]

Can you Please Explain how to do that?

The bounce-back rule