Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Global Automation Fail

I am trying to create a global automation where if 1 of 3 people are assigned on any project, then it will clone that issue into a different project. It seems like its running correctly and then fails at the creation of the issue on the other project. What am I doing wrong?


Screen Shot 2022-09-13 at 10.56.27 AM.png

2 answers

0 votes

Who is the Actor for this rule? Does the Actor for the rule have permission to create issues in the GTM Ops project?

Is the GTM Ops project a Company Managed project or a Team Managed project? Is it a Business, Software, or Service project?

Are the source issues that might trigger this rule in Company Managed projects or a Team Managed projects? Are they in Business, Software, or Service projects?

0 votes
Jack Brickey Community Leader Sep 13, 2022

Maybe a permissions issue? Who has Create issue permissions in  GTM Ops? Can you create a manual test rule that simply creates an issue in the project?

A permission set on who can add an issue to the GTM Ops project? That makes sense and I thought about that, but couldn't find where to update that. 

Jack Brickey Community Leader Sep 13, 2022

If it is a Company managed project check project settings - permissions. If it is Team Managed then any Member can create issues. I suspect the clone is being created by automation for Jira but can you go into your rule details and find the Actor?


Yes, the Actor is what you have (Automation for Jira).

What I'm trying to do is have any team or company managed project to be able to add issues to this board as long as it meets the criteria. 

For context purposes, I'm trying to show the workload for these 3 people on this one board no matter where their task was assigned. 

I just added the Automation for Jira and it failed again.

Screen Shot 2022-09-13 at 5.36.06 PM.png

@Blake Stewart 

A "board" is just a view of issues. Rather than cloning the issues into a new project, create a saved filter that retrieves the issues for these three people and then create a board that is based on that saved filter.

Do note that if you mix Company Managed and Team Managed project issues in one board you may see some unexpected behavior as the two types of projects have some differences in their architecture.

The Cloning process may be running into problems because of differences between the source and destination projects with regard to custom fields and workflows.

Like Bill Sheboy likes this

Ok, for the saved filter theory... The issue that is assigned could be from a wide variety of different projects (some that this team doesn't even know about). So would the saved filter that retrieves issues be set up on this GTM Ops Project and "listen" for issues on other projects or boards?

No, I'm saying you don't need the GTM Ops Project at all if all you use it for is to hold cloned issues from other projects. You should stop cloning the issues entirely.

You would create a saved filter like this:

assignee in (<user1>,<user2>,<user3>

That should return you a list of all the issues assigned to those users, in the projects that you have permission to browse. (If they have issues assigned in a project that you don't have access to, those won't be included.) Then you would save that filter.

Then you would create a board based on that saved filter. When you create a board you have the option to create it from an existing project, created with a new project, or create it from a saved filter. Choose that last option, and choose the filter you created and saved previously.

You would need to share that saved filter with anybody whom you want to have access to the board

Note that for anybody who views the board, if they don't have access to 1..n of the projects where the assignees have issues, then the results they see will be incomplete.

If you know that the assignees work only in Software types of projects (vs. Business or Service) you might want to also add that to the filter to improve performance.

projectType=software and assignee in (<user1>,<user2>,<user3>

Ok, I think this is making a little sense. Thank you for your patience!

The GTM Ops project board is basically for our VP to see the different things that 5+ different Ops teams are working on. All of these issues are coming from a wide variety of projects. So I see where you're coming at with the saved filter, but my struggle is needing it to read all projects or boards within our entire organization.

(Sorry, @Jack Brickey , I feel like I hijacked your response thread.)

The people who need to see the results (use the aggregating filter/board) would need to have the Browse Projects permission in all projects across the organization then. Permission to access the boards associated to those projects are irrelevant. Boards are just a way to view and manipulate issues; they are not containers for issue. 

You mentioned that you are aggregating information from both Company Managed and Team Managed projects. This can cause additional challenges since the Project Admins for Team Managed projects can change the accessibility of those projects and cut off your or your VP's access to see them.


IMO, cloning all those issues into another project is not a good way to address the problem. If you clone the issue, then you also have to have automation to keep the issues synched to the original issues from which they were cloned. Without that, the person viewing the clones will not be seeing current information. Additionally, anybody with permission to link issues could come along and unlink the cloned issue from the clone, derailing the synch process. 

You are also going to have issues with the Clone process, I believe, because your source issues may have variations in Custom Fields, or Contexts for custom fields, or Workflow statuses, and you will be hard pressed to make your GTM Ops project a repository capable of accepting all the varied inputs. Also consider that those source projects could be changed to get new Statuses or Custom fields and that could keep introducing problems into your automated cloning attempts.


Being able to produce aggregate data reports for management requires, IMO, ensuring that your data sources are managed in a manner that actually supports aggregating the data. You may find that you need to rethink how your organization is using and managing Jira project configurations in order to support management reporting requirements.

Ah! All of those cloning problems make sense. Thank you for bringing those up!

Where is it that you can change the "Browse Projects permission in all projects across the org"?


All I'm seeing is this and this doesn't seem like what you're referencingScreen Shot 2022-09-14 at 1.16.26 PM.png

There is not a global permission that allows a user to browse all issues in all projects across the system.

For Company Managed projects that is handled in the Permissions Scheme(s) assigned to the projects.

For Team Managed projects it would be handled in the Access settings of each project.

Another possible problem with visibility can be caused if Issue Security has been implemented. Issue Security can hide issues from users also. That would be governed by Issue Security Schemes assigned to projects for Company Managed projects.

These are the different permission schemes I see. Which one would you recommend?


Screen Shot 2022-09-14 at 1.27.23 PM.png

You will have to update every permission scheme that is used with a project that you want to be able to access. 

If you go to:

https://<yourJiraUrl>/secure/admin/ViewPermissionSchemes.jspa will see all the Permission Schemes defined in your instance and the projects with which each one is associated. 

Are you the only administrator for your instance? If not you may want to confer with the other administrators before making any changes.

Also, note that Permission Schemes are not used for Team Managed projects. Each of those project has its own permissions settings and each of those will have to be reviewed and adjusted as necessary to ensure access.

Jack Brickey Community Leader Sep 15, 2022

@Trudy Claspill ,

no worries at all here. We are all here to help each other. I got busy on other things yesterday. Very glad you were able to continue the efforts here and hopefully get this closed now.

Suggest an answer

Log in or Sign up to answer
Site Admin

Atlassian Community Events