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

Jira Automation - Multiple Projects - Sprint start/end events - Rules stopped working

Hany G

Hi Community,

I'm hoping someone can help as I've tried troubleshooting and just can't figure out why a couple of the Jira automation rules which were running fine, stopped working about 3 weeks ago.

Both rules run across Multiple Projects and are triggered by either a Sprint started or completed event.

The only change which was made to these rules a few days before they were due to trigger was that an additional project was added to the list, but the same was added to 3 other rules (which are not triggered by sprint events but rather issue transitions) and they're still working fine.

Audit logs don't show the rules triggering at all, last activity is that edits were made (when I added the extra project).

Many thanks in advance.

P.S. Usage is way below limits (Currently at 58 and has never even reached 300/m).

Accepted answers

Hany G

Did a search and found this bug was added to Atlassian's Jira backlog a couple of weeks ago:
https://jira.atlassian.com/browse/JSWCLOUD-21584

All comments

Bill Sheboy

Hi @Hany G

What license level of Jira Cloud are you on: free, standard, premium, or enterprise?

Have you tried to copy the rule and run it individually in the project (as a project-level rule) for the most recent change? That would help know if this is a permissions issue.

If you remove the recently added project from the rule trigger, will the rule run again?

Best regards,

Bill

Curt Holley

I think automation rules pertaining to sprints are better being set as Single project rules anyway. Keeps it all local, so to speak.

If the sprints/boards filter multi-project info, then the automation would need to be multi-project as well. but that ups the complexity factor, for sure.

Hany G

Thanks all for your responses so far and apologies for the large wait to follow up! (Things have been busy...)

To answer the first question: we're on the Jira Cloud Standard plan.

To explain more about the setup:
- We have several projects which need to be concurrently managed within one Sprint
- To facilitate this, rather than make yet another project, a multi-project board was created filtering all the projects' issues, and linked to a user, not a project. ('Location' setting)
- Since sprints are managed from this multi-project board, the sprint-specific automation rules are set to check that board for changes

I've run a few more tests, to investigate further:
- Sprints linked to a board attached to a single project: Rule runs successfully
- Sprints linked to a board attached to a single project, but which filters issues in from 2 or more projects: Rule runs successfully
- Sprints linked to a board with user as location, rather than a project: Rule fails to even be triggered

I've marked some lines above in bold as that's the confirmed issue here.
At some point roughly 2 months ago, some bug occurred which doesn't allow automation rules for sprints to trigger if that sprint is specifically set to a board with a 'user' location instead of a 'project'.

This was definitely working before.

Bill Sheboy

Hi @Hany G

I am unfamiliar with that technique/configuration: linking a sprint to a "user as location rather than a project." If you can clarify what that means and how it is done, perhaps that will help lead to suggestions. Thanks!

Best regards,

Bill

Hany G

Thanks Bill,

That's my bad with a bit of hurried wording there. I meant the board the sprint was created in had the location set as a user, rather than a project.
I've clarified it now.

To further elaborate: on creating a new board, if you pick the last option "Board from an existing Saved Filter", on the next screen you get the option of setting the Location to your own personal profile instead of a project - you just start typing the profile name and it'll come up.

This is the specific scenario that's failing now.
Automation rules, supposed to be triggered by Sprints which are running from a board linked to a user profile (not a project), aren't being triggered.

Hany G

Did a search and found this bug was added to Atlassian's Jira backlog a couple of weeks ago:
https://jira.atlassian.com/browse/JSWCLOUD-21584

Bill Sheboy

Thanks, and wow: I just learned a new Jira feature: boards without projects! (Although, I am unclear why anyone would use this...at least until we have read-only boards for leadership people. ;^)

Anyways...I believe I just replicated that defect for sprint closure when investigating this feature. After creating such a board connected to a profile, I note that:

It cannot create sprints; it can only see the sprints from the issues exposed through the filter..and
I can edit or delete sprints from this board's backlog
I can complete the sprint from the board
I cannot create automation for the board's issues. It cannot even see the automation rules.
When I created an automation rule within a project, I could only point to that profile-specific board after I changed the rule actor to my user account...And...
I created two test rules, both triggered on sprint completed and for 2 different boards: a project board and the profile board. When I completed the sprint from the profile-board, the project-board rule triggered.

My recommendation: put your shared visibility board in a project, not a profile, in order to have better likelihood the automation rules with fire.

Best regards,

Bill

Hany G

Thanks for looking into this, Bill! And sorry for the long wait - things have been busy

It's odd that you weren't able to create Sprints, as that should have been possible through that board's backlog - it's true that it'll also surface other sprints that the issues the filter exposes might to be placed in (However that's why I tried to run all the team's tasks through that one sprint board - Pros and Cons as usual to any solution!)

Since it's a confirmed/identified issue in Atlassian's Long Term Backlog, I've attached the board to a project for now to get around the issue; perhaps I'll revisit in a couple of years when it might be fixed!

A pleasure exploring this with you; hope our paths cross again

Welcome!

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

Quick Links

Find more posts tagged with

cloud

automation