[SOLVED] Branch on Linked Work Items with a Scheduled Task not working as expected

[Erica Robinson]

I'm currently working on building out an automation that runs daily to review specific work item types in a specific status. If any are found, I need to add a comment to their linked items that they still need an update. I have also tried to add the JQL outside of the scheduled task and it didn't make a difference. Should I be using a lookup instead here?

Here is the rule breakdown:

Rule details:

Audit Log:

Confirmation that there is a linked item on GD-18473:

[Trudy Claspill]

Hello @Erica Robinson 

What is the Space type of the SOFTSUP space?

Can you try changing the actor of the rule from Automation for Jira to yourself?

If the rule then runs successfully and if the SOFTSUP space is a Company-managed space, then check the Permissions Scheme associated with SOFTSUP and confirm that the Browse Projects permission is allocated to 

That permission allocation is required for the actor Automation for Jira to be able to see the space contents.

[Erica Robinson]

Hey @Trudy Claspill 

Thank you for the quick reply!

What is the Space type of the SOFTSUP space?

SOFTSUP is a Service Space. GD is a Software Space.

Can you try changing the actor of the rule from Automation for Jira to yourself?

I just tried this and the results were the same unfortunately.

I've also confirmed that the role atlassian-addons-project-access has all permissions available in each space including Browse Projects.

[Trudy Claspill]

Was the SOFTSUP item linked to the GD item at the time that the rule was executed (9:03:00)?

In my own experiments I found that if the "project = XXX" condition within the Linked Work Items branch failed, then in the rule execution log it would report that no linked issues were found. I tested that against an issue that was linked to many issues in many different projects. When it did not have a link to an issue in the project specified in the condition, then I got the same status message you get.

[Erica Robinson]

Yeah, it's been linked since Dec 23, 2025 at 11:41:00 MT.

Let me play around with the JQLs I have and I'll report back.

[Erica Robinson]

So I did some additional testing and found that when using JQL after the branch, it fails - it didn't matter what the JQL was. As soon as I removed the JQL it worked as expected.

This isn't ideal as we want to pinpoint only one project (possibly two) that have the ProdBug linked to them. The others wouldn't be needed.

[Edited to add]

I just tested using the "IF condition: Work item fields" and used project and it worked just fine. So it seems to be an issue with JQL directly, not the condition it's searching for.

[Bill Sheboy]

Hi @Erica Robinson 

Which of the JQL conditions you show in the earlier rule was not working as expected?

And...as an alternative, have you considered using a Branch on JQL (rather than linked work items) and adding all the necessary conditions to the JQL for that branch: linkage to the trigger item, project, status, and when the status changed?

Kind regards,
Bill

[Erica Robinson]

Hey @Bill Sheboy 

Neither of them are querying the linked items. I can confirm that the JQLs - when selecting 'Validate Query' - do return results and that the work item is linked to the ProdBug. I tried using each of them individually and kept getting the "no issues found".

The issue I'm running into is that when IF JQL statements are used after the Branch to ensure I'm only filtering for either a specific project or a specific status/status change for these linked items, I'm getting no results.

If I remove the JQLs entirely, I get the linked items as I expect to. I also get results if I use other IF options - such as work item fields.

To be able to use the linkedIssues() function, don't we need to have scriptrunner? If so, then I won't be able to use that as we haven't been approved for it's usage.

[Bill Sheboy]

Hmm...I want to test that symptom further to understand what is happening with the conditions in the branch.

In the interim, the linkedIssues() function is a built-in JQL one, so you could try this:

issue IN linkedIssues( {{triggerIssue.key}} ) 
  AND project = SOFTSUP 
  AND status = "Waiting on Internal"
  AND NOT status CHANGED AFTER -48h

Please adjust that for your specific needs, such as including additional projects or the link type.

[Erica Robinson]

Ugh. I think I found the issue. I thought I had adjusted the status of the SOFTSUP ticket, but I didn't. I appreciate both of your input @Trudy Claspill @Bill Sheboy . I appreciate your patience.

[Trudy Claspill]

In my testing having the JQL condition within the branch did not cause 100% failure. Here is an example where the issue found by the Schedule trigger JQL

key in (CS-85)

... has multiple issues linked to it from other projects, including one issue linked from the CUS project.

The rule scope is Global and the actor is Automation for Jira.

The source project is Company Managed Software and the CUS project is Company Managed Service.

This is in a Free instance with no customization of Permission schemes and no Issue Security Schemes applied.

[Trudy Claspill]

Ah, so it isn't the JQL condition to check the project but rather the following JQL condition that looks at the linked issue Status and Status Change date.

It crossed my mind to wonder if the second JQL condition was being met, but then I got distracted ;-)

[Erica Robinson]

Yeah it was the full failure that was tripping me up. We should be all sorted now ^^;

I really do appreciate both of your attention on this - even thought it was just my mistep.