Global automation rules doesn't execute correctly
Asked by Xavier Lenne:

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.


Answers:
author: Marc - Devoteam
body: Hi [@Xavier Lenne](/t5/user/viewprofilepage/user-id/5425266)

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.

comments: author: Marc - Devoteam
body: See documentation here on [scope](https://support.atlassian.com/cloud-automation/docs/what-are-rule-details-in-atlassian-automation/#:~:text=name%20field%20provides.-,Scope,-This%20will%20impact)


author: Xavier Lenne
body: Hi [@Marc - Devoteam](/t5/user/viewprofilepage/user-id/3796976)   

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](https://community.atlassian.com/t5/image/serverpage/image-id/305735i4C6B369959C9E7E8/image-size/large?v=v2&px=999 "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.


author: Marc - Devoteam
body: 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.


author: Xavier Lenne
body: 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.


author: Marc - Devoteam
body: 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.


author: Xavier Lenne
body: 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 understand![Atlassian_02.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/305754iC22481667BB35903/image-size/large?v=v2&px=999 "Atlassian_02.jpg")


author: Marc - Devoteam
body: 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?


author: Xavier Lenne
body: On this case, he did nothing.![Atlassian_03.JPG](https://community.atlassian.com/t5/image/serverpage/image-id/305760iE520AECDDD34A626/image-size/large?v=v2&px=999 "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..


author: Marc - Devoteam
body: 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.

comments: author: Xavier Lenne
body: Precisely, it is only on EVO that it triggers, on any other project, it simply does not activate.


author: Marc - Devoteam
body: 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()


author: Xavier Lenne
body: 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.


Tags: jira-service-desk-server

jira-service-management

jira-service-management-server