Sprint Started automation for a board from a different project doesn't trigger

[joe.drew]

I've got a project that pulls from multiple other projects, and when a sprint starts, I'd like to transition all the issues in that sprint to a different status. I've created automations in each of the other projects that look at the board in question, but the audit log shows they're not being triggered at all.

Specifically, I've got IOS and AND projects, each of which have automations with the "When" set to the "parent" project (HMM)'s board.

I don't actually care where these automations live, but I do need to transition two different types of issues, and my understanding of the "Rule restricted to projects" restriction means I need two different automations.

[Bill Sheboy · Accepted solution]

Hi @joe.drew 

My understanding is a sprint is owned by a board which is owned by a project. 

• In which project is your HMM board and is that the sprint which you are starting?
• For your branch, is the triggering Sprint in the same project you are selecting in the branch, IOS?
• Are these company-managed or team-managed projects?

To do what you ask, I believe you would need separate rules by project, stored in the project.  There wouldn't be a need for global rules.

Kind regards,
Bill

[joe.drew]

Hi @Bill Sheboy

Thanks for your reply! Here are some answers to your questions:

• HMM is a project with the HMM board, and the sprints are in the HMM board.
• The triggering sprint isn't in the IOS & AND projects, no. (IOS and AND are separate projects, and their tickets are included in the HMM board & sprints.)
• They're all company-managed projects.

I've currently got those project-level rules; unfortunately, they do nothing :(

Thanks!

joe

[Bill Sheboy]

Joe, would you please post an image of your rule Details section?  As this is actually a multi-project rule, you probably need the relevant ones noted in the details.

[joe.drew]

You bet, Bill! Thanks for the reply.

I don't actually have the ability to edit "Scope" on that — it's a Project rule, not a Global rule.

[Bill Sheboy]

Thanks, Joe.  More questions:

• For the IOS and AND projects, do they have boards of their own?
• If so, are they Kanban or Scrum boards?

I am trying to replicate your use case in a free instance to try to reproduce this symptom. 

[joe.drew]

Thanks, Bill! They do have boards — in fact, they have a bunch, both Scrum and Kanban. (Though we could probably delete the Scrum boards, since we don't use those at all.)

[Bill Sheboy]

Thanks for that information, Joe!

I reproduced what you saw, as follows:

• created three company-managed projects: HMM, AND, IOS
• for the HMM project, I added a Scrum board with a filter spanning all three projects
• created issues in each project
• created a sprint in the HMM project, adding issues from all three projects
• created automation rules as you described in the AND and IOS projects, triggered on the HMM board's sprint but trying to update issues in AND and IOS, respectively
• started the sprint in the HMM project

Neither of the rules triggered.  This appears to either be a defect or by-design, as the trigger does not see the sprint (owned by HMM) even though the trigger is selecting that board.

As a work-around, I created a multi-project rule for all three projects, and it works as you expect.  This solution may not be ideal for a Jira Standard license, as the number of global/multi-project rule executions is limited per month.

To confirm if this is by-design or a defect, please work with your site admin to submit a ticket to support here: https://support.atlassian.com/contact/#/

Once you hear back from them, please post what you learn to help the community.  Thanks!

[joe.drew]

Wow, thanks, Bill!! Very, very helpful. I've pinged my site admin to file this bug, and I'll keep y'all up to date.

joe

[joe.drew]

Atlassian support got back to me and said that "as the Board is set on another project outside of the scope I'm afraid the Automation is not able to know that the Sprint started and thus the rule is not triggered."

The solution, therefore, is to: "set a Global or Multiple project scope for the rule, this will count towards your Global Automation Rule limit of 1000 executions, it will use 1 execution per Sprint started."

Oh well! Was trying to avoid global-scope rules, but them's the rules.

Thanks so much for your help, @Bill Sheboy!

[Bill Sheboy]

Thanks, Joe! 

You may want to ping support again to confirm that information about execution limits, as current pricing shows 500 per month for a standard license site.  Perhaps there is some "grandfathering" for customers prior to the latest changes.

Customers on Free and Standard plans have access to a limited monthly trial allotment of global and multi project rule executions (100 and 500 per month, respectively).

https://www.atlassian.com/software/jira/pricing

And if you decide to go with the global rule, work with your site admin to add a rule to watch for approaching your service limits with the trigger below.  We do this to notify the site admins if we have a problem.

https://support.atlassian.com/jira-software-cloud/docs/automation-triggers/#Automationtriggers-Servicelimitbreached

[joe.drew]

Atlassian support also filed this ticket on my behalf, saying it'd be better to not make it possible to think that these rules would work: https://jira.atlassian.com/browse/JRACLOUD-77890

[Bill Sheboy]

Thanks, Joe! 

Limiting scope for dropdowns, etc. has been an ongoing challenge for Jira.  And some of the design choices for team-managed definitely make that worse (e.g. cloning all the status values for each project).

__Bill