Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Global automation rules doesn't execute correctly

Xavier Lenne February 9, 2024

Hello,

We use several automation rules in the "Global" application but restrict them to around twenty projects out of a total of more than 800 projects. During the execution of this automation, it runs only on a single project, which is not the first in the list and, moreover, without making any intervention. At least for this particular project.

Where could the issue be located regarding the fact that, during the execution of the automation, it runs only on a single project, even though it is assigned globally but restricted to about 20 projects?

The automation itself has no issues; I want to clarify that the JQL is valid.

I appreciate your prompt response.

2 answers

1 vote
Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 9, 2024

Hi @Xavier Lenne 

Welcome to the community.

Your thinking is wrong.

The automation you made is used on projects specified in the scope, that does not mean that if the automation is triggered based on the trigger and conditions and actions specified in the rule

So if an issue in one of the projects specified in the scope of the rule relates to the trigger of the rule, than the rule will run.

Can you provide screenshots of your rule and details on the steps and what you expectation is.

As I mentioned before the scope of the rule only means that the rule can be executed in those projects if an issue in the project is created, updated or else.

Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 9, 2024

See documentation here on scope

Xavier Lenne February 11, 2024

Hi @Marc - Devoteam 

Thanks for your time to respond.

Here a screen shot of the scope and a step in it. This step is "if in customefield (Select list) is"

I've just mask the name of project for security reson.

Atlassian_01.jpg

The step when it's trigged, create a sprint with correct name and with a message on comment to notify the beggining of this sprint soon. and link all necessary (if 0 then no attachement) sub-task to the issue.

Again, thanks for your time.

Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 12, 2024

But what I see here is and what will happen is:

Rule is run when issue is created, then the scope is on play. It's immediately checked if this issue is in any of the projects defined in the scope.

If this is true, the rule will run. But the rule runs on that issue in that project only.

This is default behaviour.

Xavier Lenne February 12, 2024

Um. So if I understand correctly, automation stops as soon as it runs at least once? in this case, with a project that does not have these famous customfield.

Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 12, 2024

No.

The scope reflects to projects the rule is able to execute in. The scope is not that if an issue is created it will run on all projects int he scope.

So if you create an issue in Jira, this automation checks if the projects is in scope of the rule and if this is Yes, the rule is executing.

But depended on the rules settings it can still fail, as conditions or edit action are false on executing.

Xavier Lenne February 12, 2024

But as ou can see, it only works with one project, and it's not the one with we do our test. It's that i don't understandAtlassian_02.jpg

Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 12, 2024

Hi,

So I expect project EVO is in the scope.

What does the audit log show on the no actions performed?

Are all custom fields an or system fields you have a condition or action on in the rule available on the EVO project?

And as the rule runs on issue creation, are the fields that are being set or edited on the create screen of the issue type?

Xavier Lenne February 12, 2024

On this case, he did nothing.Atlassian_03.JPG

"EVO" haven't the customfield needed, he's just a part of a group of project. We've done our test with onather project, but as you can see, he doesn't appear..

0 votes
Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 12, 2024

So based on the log action.

An issue was created in project NUM, the project is in the scope, otherwise the rule wouldn't have been triggered.

The issue created NUM-20201 doesn't result in TRUE on the JQL condition, so the rule doesn't comply for issue NUM-20201 and therefore no action is performed.

This is exactly the action and response that is expected from your rule.

To have the rule triggered in project EVO, you need to create an issue in project EVO.

As I mentioned before the scope is not determining that the rule will run in on every project in the scope when an issue is created. The scope is only related that the rule is able to run on the set projects, based on if there is an issue created in one of the scoped projects, and than runs on the project where the issue is created.

Scope does not mean the if the rule triggers it runs on all projects in scope, that is not how automation works.

Xavier Lenne February 12, 2024

Precisely, it is only on EVO that it triggers, on any other project, it simply does not activate.

Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 12, 2024

So your JQL is the issue and I think this is baed on the fact the your JQL refers to a specific sprint.

Sprint = Cyber, this sprint only exists in project EVO correct, not in other projects?

So remove this clause and the future and closed as openSprints is the only. clause that requires to be true.

JQL: sprint in openSprints()

 

 

 

Xavier Lenne February 12, 2024

He doesn't exist on EVO, he'll be present in other projects of the scope but not in EVO. In this rules EVO can't be remove just for the linking of sub-task. It's the only use case of his presence in the scope.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events