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; } } }

Automation 'Issue Commented' triggers too much automation events for our subscription

Marc_ezoqxw

Hi,

I currently created an automation rule that if an issue is commented by a customer AND the status is 'waiting for customer', the status needs to be changed to 'work in progress'. See screen shot below

Problem is that this automation is triggered a lot on daily bases, so we exceed our automation limit of 500 automations (standard plan) within 2 weeks.

Is there another way I can set up this automation, so we don't exceed our automation limit? Most automations do not lead to an update, because most comments that trigger this automation are internal comments and not customer comments.

A solution using the scheduling trigger would be ok. We are using Jira service management team based.

Accepted answers

Jack Brickey

Is this a global rule or a project rule? If global, then definitely move away from that because comments will exceed the limits rather quickly. If you already have the set up as a project rule then there’s little you can do if indeed your trigger needs to be a comment.

Marc_ezoqxw

Just found the article below. Single project automations are not included, in the automation usage, so that work around should work.

How is my usage calculated? | Jira Software Cloud | Atlassian Support

All comments

Jack Brickey

Alex Koxaras -Relational-

Hi @Marc and welcome to the community!

What @Jack Brickey said is true and I agree with him. However, because I faced a similar thing with a client of mine, the solution that I proposed to them was to have every automation within the workflows. Workflows uses REST API to do stuff and their limits (although unknown) are higher than that of jira automation. My advice would be to take advantage of this situation (e.g. JMWE has a listener about field value changes. Perhaps other applications have this as well).

Marc_ezoqxw

@Jack Brickey , currently this is a global rule, because it applies to all projects. About our set up: Per country we serve, we set up a separate project, because each country has its own service organisation. But for each country / service organisation, this rule needs to be applied. So I can remove the global rule and make a separate rule per project, but then the number of trigger will stay the same in my opinion. Or do I miss something?

@Alex Koxaras -Relational- , thanks for your reply. Unfortunately my skills don't go that far.

Marc_ezoqxw

Jack Brickey

Correct, this was implied in my Oct 8th comment.

Welcome!

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

Quick Links

Find more posts tagged with

next-gen

jira-service-management-cloud