Global Automation: When Sprint Started trigger not working

[Benny]

I created a new rule in Global Automation using When Sprint Started trigger, but it is not running when I started a new sprint.

I have 5 projects and a scrum board (named RD Board) with simple filter query "order by created DESC", so in the board I can see all projects issues.

The sprint was started in the RD Board.

Here are the setting details in screen-shot:

And the RD Board settings:

The sprint started in RD Board:

In the Global Automation's Audit Log:

The Automation Usage:

The "In Active Sprint" custom field:

My account used to login is Jira Admin (full access).

Is there anything that I missed in the settings or something not correct? Please help.

I have been struggling with this rule since yesterday, I need this rule on Friday to show the management, we are new in using Jira.

Thanks.

Regards,
Benny.

[Bill Sheboy · Accepted solution]

Hi @Benny -- Welcome to the Atlassian Community!

You appear to have a board which is including every project in your instance, and you are creating a sprint for that.  Is that correct?

If so, the sprint-related triggers cannot work for the All Projects setting of global-scope automation rules.  There are several suggestions to change that behavior, including this one: https://jira.atlassian.com/browse/JIRAAUTOSERVER-496

My recommendation would be to narrow your scope, select the specific projects you want in the board filter and in the rule settings, and then test again.

Next thing to watch for: are your teams using Company-managed, Team-managed, or both types of projects?  If both, I would expect some failure results for this rule trying to set the custom field...unless you have started using the new feature of Team-managed projects to re-use site-defined custom fields.

Finally, I am curious: what problem are you trying to solve having a board with all projects in a Premium license level of Jira Cloud?  I would expect that to have a large number of issues and projects.

Kind regards,
Bill

[Benny]

Hi @Bill Sheboy

Thanks for the response.

Yes we will have all projects in one board because we only have small team that will manage the sprint, that will be too many work if we maintain many sprints (one sprint one project).

All projects are company-managed project, we disabled the team-managed project creation in permission scheme.

What we try to do here is we will have 2 boards, one for R&D team (RD Board) and one for QA team (QA Board), because of the nature of the team's work the development done issues in R&D cannot be immediately send to QA team for QA process. The QA team have their own schedule to do the QA.

R&D's sprint and QA's sprint may have different time-frame, they managed their own schedule. When RD's sprint completed (closed), all the development done issues will be moved to QA's backlog. The same with QA, when QA's sprint completed, for the issues with QA failed status will be moved back to RD's backlog.

I try to use custom field to track and navigate the issues, that's why I think I will need a lot depend on global automation's When Sprint Started and When Sprint Completed triggers.

The Project in Jira is represent our customer, currently we have 25-30 customers, so that will be 25-30 projects, and there will be big amount of issues.
It is too much effort if we need to setup automation in each project.

25-30 projects are actually not big, but we don't have many resources if we do it with multiple sprints.

If the When Sprint Started trigger is not the right choice then I will need to think of other approach.

Regards,
Benny.

[Bill Sheboy]

Thanks for those additional details.  I am still unclear on the purpose of the rule from your question, as it seems to just set a custom field in all issues included in the sprint...which would be spanning multiple projects, in your case.

You do not indicate if you are using parallel sprints, and so I wonder if there are more criteria to select issues which are on the RD versus the QA boards.  If so, you may be able to use that to change issues to match your workflow.

Regardless of that, I again suggest trying to work-around the limitation on not using All Projects with that rule, and instead try to add all of your projects individually to the rule.  This approach will require on-going maintenance, but it may help.

[Benny]

Initially I was hoping to use the field in the transition's condition, user will be prevented to do the transitions if the issue is not in the active sprint if the field value "In Active Sprint" is not Yes.

I've tried to use "Multiple projects" in scope instead of "All projects", the rule still not run. And tried the Allow rule trigger checkbox also not run.

Before the rule was running as expected, but it was in the board that is belong a project, not multiple projects.

After doing the research and since we cannot use the rule in this kind of board, we decide to let it go by not preventing the issue to be transitioned if not in active sprint.

It actually would be very helpful (I believe many users too) if there is an easy way to identify the issue is in active sprint or not, I know we can do JQL to identify this (using openSprints function), but we cannot do this in transition's condition or validators, or may be condition in automation something like "Issue in Active Sprint", etc), as far as know (or can we?).

I know there is a ticket for this kind of requirement, https://jira.atlassian.com/browse/JRACLOUD-71690, but we cannot wait for that uncertain status (gathering interest) whether or not it will be implemented.

And I know that we can use Scriptrunner (as I read in the community discussions, never try this yet), but we will not go into this path, as yet.

Regards,
Benny.

[Bill Sheboy]

I am going to try some tests around your use case...

In the meantime please note that the Allow Rule Trigger option only applies to one rule creating conditions to trigger another rule.  I do not believe that applies to your scenario, unless you have a rule which is starting the sprints.

[Bill Sheboy]

I just tried your scenario with a free license Jira Cloud project and it worked; the global automation rule triggered on Sprint Started with All Projects selected.

And, I think I see the problem...the board filter for RD Board appears to be private to just you; it has no shares.  But I suspect that board is part of a project, and not a personal board associated to your profile.

Please try editing the board's saved filter to share it with others and then retest.

[Benny]

That's strange if it works on your side. I tried again and it still not working, please see following screenshots:

Global Automation:

The RD Board filter query share is set to My organization, editor is group-sprint-manager:

Then I started a new Sprint in RD Board, there are 5 issues with different projects:

Checked the issue's "In Active Sprint" field, the values are all none, expected is Yes:

The Automation's log showing no rule was executed:

The Sprint was started using user level account, which is a member of group-sprint-manager. The group-sprint-manager have permission to Schedule Issues:

So, are there any other settings that maybe be missed here?

[Bill Sheboy]

I wonder...Your board is located in the RD Lead project, correct?  If so, is the RD Lead project also listed in the projects for the rule?

If that is not the cause, I am out of ideas on this one.  You appear to be on the Premium license level and so global rule execution is unlikely to be the cause.

Please consider working with your site admin person to submit a ticket to Atlassian Support, as they may see something we are missing: https://support.atlassian.com/contact/#/

When you hear back from them, please post what you learn to benefit others in the community.  Thanks!

[Benny]

I see... The RD Board was located in the RD Lead, and RD Lead is a user, not a project.

So, now I moved the RD Board to project, I created a new dummy project for RD Board's home (location), like this:

And included the Z_RD Board project in the automation rule, started a new sprint, and it works! The In Active Sprint field got updated to Yes.

So the lesson learn here is that the board must also located in one of projects that listed in the rule's scope.

I tried create a new copy from the same rule and changed the scope to "All projects" and it is also work. I don't have to use Multiple projects scope and adding a new project each time.

Thanks Bill for helping me out here.

[Bill Sheboy]

Awesome!  I am glad to learn that helped.

I recall seeing (or submitting) a defect that some of the automation triggers do not work for a board located in a user's profile.  The missing project's context seems to be the key that prevents them receiving the event.