help to reduce automations in response to plan changes
Asked by Phillip C:

With the upcoming [automation restrictions imposed by Atlassian](https://www.atlassian.com/blog/announcements/cloud-automation-packaging-update), I would like to know if there are ways I can reduce the automations required to run.

I have a fair few rudimentary automations that perform actions based on the email address or summary of a ticket, but I don't think the automation rules have much more to help reduce the amount of times these automations are triggered?

Any help is appreciated.

![Screenshot 2023-10-16 100419.png](/t5/image/serverpage/image-id/286388i52E7539F493A027B/image-size/large?v=v2&px=999 "Screenshot 2023-10-16 100419.png")![Screenshot 2023-10-16 100440.png](/t5/image/serverpage/image-id/286389i033F67C498F54FAF/image-size/large?v=v2&px=999 "Screenshot 2023-10-16 100440.png")


Answers:
author: james.cattermole
body: If you remove the option to email a project and get users to request via the portal you can reduce automations used to triage emailed requests.

Using a portal enables users to select the correct type of request that can then be assigned to an issue type directly.


author: Matthias Gaiser _K15t_
body: Hey [@Phillip C](/t5/user/viewprofilepage/user-id/4276845)

I have some tips which we've checked out for our own automation rules:

1. Make sure that the **first action in your rule is a condition** which executes this rule only in the necessary cases. This way the rule results in a "No action" result and therefore doesn't count against the limit.
2. Depending on your use case, you can possible **switch some automation rules from an issue creation trigger to a scheduled one**, so that the scheduled rule runs e.g. every day and performs the same action on all issues created within that day.
3. You can also **combine several rules into one** , e.g. the two rules you've listed above could be combined, so that they're not counted twice.  
   I don't like that change too much since the administration is harder, but you'll end up with fewer rules.

Maybe some more people have additional guidance.

Cheers,  
Matthias.

comments: author: Phillip C
body: thanks Matthias. However, the conditions to check for the somewhat simple details of an email sender or description or even summary of a ticket received is still counted towards automation consumption. But I'm happy to be proven wrong here!

I've definitely considered just morphing a bunch of conditions into a few larger automations that run on a schedule.. but that's against the principles of operating a service management project - I've SLA's and work to do. I also don't want to add additional filters for tickets where automation rules will be 'eventually' dealing with them.


author: Matthias Gaiser _K15t_
body: [@Phillip C](/t5/user/viewprofilepage/user-id/4276845), I got triggered by the other comment to have another look at your post and wondered if you solved it for yourself already?

If not, I might have one more idea: If you omit the re-fetching of the issue data, your automation might actually be considered to run with "No action performed". We don't refetch the information for our rules which works fine for us - not sure if you have a specific reason to add it.


Tags: cloud

jira-cloud

jira-service-management

jira-service-management-cloud