I set up Jira automation for multiple projects and when the rule is created, the first step is to add issue triggers which kick off events for all the projects until it hit the conditions which can only be added in the subsequent steps.
I only want the event to be generated for 1 project because when multiple events are created even when no actions are performed, they count towards Jira executions and usage for multiple projects. With multiple events occurring during the day especially on Service Desk tickets, we're reaching our execution limit before it gets reset at the end of the month.
Hi @kurshid.rostom ,
I don't think there is a way to get around the multi project usage for this scenario. There will always be some kind of evaluation to check if the issue matches certain conditions.
My best suggestions is to rethink the trigger. I'm guessing you might be using the "Field value changed" trigger which will run anytime the issue is update. Here are some alternatives (I haven't vetted all these):
I hope that helps.
I did try the first 2 options but if I use "Issue assigned" trigger, I can't reduce the number of fields in the trigger. I've used "Field value changed" for assignee but it will still log "No actions performed" because when the assignee changes on one of the projects, it will still log it even if it doesn't meet the conditions.
The schedule trigger isn't an option for us because we want to see real time updates on customer tickets.
I think the main issue that needs to be addressed is that "no actions performed" shouldn't count as usage for multiple projects just like single project rules are not counted towards the execution limit.
Since some of the triggers that are offered can't be configured, and conditions can't be added in the first step, only rules with success status should count towards the limit.
I had to disable some of them yesterday because we were very close to our limit and will have to wait until the end of the month when the limit is reset to re-enable them. I wish there is something that can be done about this.
Thanks for the feedback on creating more configurable triggers, I'll pass this on to the team.
Unfortunately with some triggers we need to execute the rule to evaluate the conditions because the trigger event doesn't contain the information needed. So even though no action was performed we still need to run the automation to know that.
I'm sorry to hear you've had to turn off your automations 😞 I'll look into some more trigger options for you but without upgrading either Jira Software or Jira service desk to premium it might be hard to stay within the usage limits.
Hey @John - I have the same issue, I need to check a value when an issue is created before I do something. But it fires on every issue create on dozens of projects which means over 5,000 executions per month just with that one rule. We really need the ability to embed a condition in the actual trigger which determines whether the trigger even fires or not.
We won't be making any changes to our Jira triggers at the stage.
The trigger events don't have the specific information you want to filter by (e.g. in your case you only want the rule to run if there are linked issues). The automation has to run in order to fetch this specific information. As soon as that automation is run it counts towards usage.
To solve this you can increase the number of multi-project and global rule executions. Jira Cloud Premium will give you 1000 multi-project and global rule executions per user, per month.
I need to set it up as global rules for multiple linked projects. To give you an example, the customer ticket is linked to a development ticket. When there is an update in the development ticket, it's updating the customer ticket which is working as expected.
However, what's also happening is if there is a change in a development ticket that's not linked to a customer ticket and vice versa, events are triggered with no actions performed. I want to exclude these from the audit log because they are counted towards execution and usage.
The major issue with the automation rules for linked projects is that when the rule is created, the first step is to add a trigger and not a condition. So events are triggered for all issues until it reaches the conditions and then log all these events (success and no actions performed) in the audit log.
I hope this makes sense
Background When you hear the words ‘Release notes’, almost always you think of an unsolicited email from a software vendor. But I am here to tell you that from our data, sending release notes via E...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events