nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

If I change a new workitem to "In Progress" and then old workitems change to "Open"

Artur

Hi Atlassian Team & Community!

Today I asking myself, if it's possible to create an automatic rule for the case:

If I am as an assignee set my current workitem to the workflow "In Progress", then my older workitems changes to the workflow "Open".

My rule idea is pretty simple:

Trigger Workitem transitioned: From each workflow status to "In Progress"
If-Condition: Initiator belongs to Team Support
Branch for JQL
JQL: assignee = {{triggerIssue.assignee.accountId}} AND status = "In Progress" AND key != {{triggerIssue.key}}
Action: Work item transitioned to: "Open"

When I test this rule, I get an error in the branch: "no related issues found", but the rule runs successful. That means my older workitems don't get transitioned, only the started trigger workitem is changed.

Now I am asking myself, if that's possible to do?

The goal of this rule is part of the bigger project to enable that new tasks will be ranked oder ordered by AI and transfer it to the Kanban board for the next free employees to get the next priority task.

Thank you for your help

Best regards

Accepted answers

Nikola Perisic

Hi,

Automation rule needs to trigger when there is a change on the field:

Shaik Riyaz

Hi @Artur,

Yes, this is definitely possible! The reason your branch says "no related issues found" is almost always due to one of these two things:

assignee = "{{triggerIssue.assignee.accountId}}" AND status = "In Progress" AND id != {{triggerIssue.id}}
Rule Scope:
If your rule is created under a single project, the JQL branch will only look for issues within that project. If the older tasks live in another project/board, change the rule's scope to Global or Multiple projects in Rule details.

Thanks!!

All comments

Nikola Perisic

Hi,

Automation rule needs to trigger when there is a change on the field:

Artur

Thank you for your reply.

You added to your JQL the parameters project. Is including project mandatory? can't it work based on assignee and key?

Nikola Perisic

You should include either your project name or the project key where this needs to happen.

Mihai_LeanZero

Check "Only include work items that have changed since the last time this flow executed" on the JQL branch first. Ticked by default on new branches. For this it should be off.

Rebuilt it on a test site. Box on, the rule adds an updated-since-the-last-run filter and older In Progress items nobody touched get skipped. Box off, both moved. The branch line in the audit log had "that have been updated since the last time this rule executed" in it.

Your "no related issues found" could be either. Open the branch row and read the full line, because plain "No related issues could be found" is probably scope, older items in a space the rule doesn't cover.

Project isn't mandatory btw.

JQL is fine as written. Only error I got was a trigger item with no assignee.

Lalithesh

Hi Artur,

Yes, you can skip the project in your JQL. The automation rule will run based on the configuration i.e., if you configure it to run in a single project, the JQL will only fetch the work items from that project.

You can also configure it to run on multiple projects or Global (all projects) - you need admin access to do this.

Cheers!

Shaik Riyaz

Hi @Artur,

Yes, this is definitely possible! The reason your branch says "no related issues found" is almost always due to one of these two things:

assignee = "{{triggerIssue.assignee.accountId}}" AND status = "In Progress" AND id != {{triggerIssue.id}}
Rule Scope:
If your rule is created under a single project, the JQL branch will only look for issues within that project. If the older tasks live in another project/board, change the rule's scope to Global or Multiple projects in Rule details.

Thanks!!

Artur

Thank you for your reply. Your first comment helped me to find the solution in my rule.

You mentioned workitem id, but I used the workitem key, which caused the issue that jira couldn't find related workitems.

I expect the reason to be that the workitem key demands the same project for the triggerIssue and the other issues. While Id compares looks at all workitems with the same assignee and in progress.

But even if my reasoning might be wrong, but the rule is working now. I just swapped workitem key for workitem id.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud

automation

jira-service-management