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

How to Sync issues related to different projects

Mohammed A_n6tncx

Hello everyone,

I have a situation that I hope to explain it well, we have a department that has several teams who are responsible to solve the bugs in our products (every team has a different project to solve these bugs), I want to build a single project for my organization that helps anyone from any other department who has any bug to create an issue in single project and then this issue will automatically open in the responsible team's project and these two issues have to be synced all throw their workflows (putting in mind that these issues have the same name and same workflow).

I know how to create the other issue (using the post function), but the question is how to use the automation rule to sync the two issues all throw the workflow?

Accepted answers

All comments

Trudy P Claspill

Hello @Mohammed A

Welcome to the Atlassian community.

I think you need to back up an look at the problem you are trying to solve. You have told us what you think the solution is (having two copies of every bug), but that may not really be the best solution.

What exactly is the problem you are trying to solve? When we understand that we can provide better advice about ways to solve that.

Addressing the questions for the solution you have proposed:

Exactly what data do you want to synch? Do you want to keep the statuses in synch? Comments? Worklogs? Every change to every field?

Do you need it to be a two way synch or one way (from the team's project to the "central" project)?

I notice that your post tags indicate you are using the Free product plan. The number of automation rule executions per month is limited baed on your product plan. In the Free plan you get only 100 automation rule executions per month. This will make it impossible to use Automation Rules to keep issues synchronized if you want full synchronization of all data. You are very likely to exceed the limit of rule executions well before the month comes to an end.

Mohammed A_n6tncx

Hi @Trudy P Claspill

let me try to explain the problem that I’m trying to solve, my problem is that we have several teams in the back end, each one of them is responsible for specific types of issues that will be raised by the external departments.

the external departments usually have a confusion of who is the responsible team of the problem they have, so we want to create central project with many issue types, others can create the ticket and we can automatically transfer it to the required team in their own project.

I want the two tickets to be mirrored so the reporter can check the status and follow up on the updates.

Regarding the data to be synced, I think the status and resolution is enough, no need for the comments (but if there is a way to sync everything, it would be helpful)

And I need it to be on way (from team’s project to the central project).

please let me know if there’s anything still not clear.

Note: it’s not free product plan, I’m not sure which plan we are using, but I don’t have any problem with the automation rules.

Trudy P Claspill

Note: it’s not free product plan, I’m not sure which plan we are using, but I don’t have any problem with the automation rules.

I want to first follow up on the rule execution limits, and why you need to think about them. I don't know your level of administration expertise in this area, so I may state things that you already know or have considered.

How many issues do you expect to handle in this manner? Unless you are handling a very small number of issues or on the Enterprise plan, there is the potential that you could run into rule execution limits.

Each time a new issue is created in your central project you want a rule to run to recreate the issue in another team's project. That's one execution.

Each time the Status changes on the copy made in the other team's project you want the issue in the central project to update. How many times do you expect the other team to change the status on each issue? I would guess that there would be a minimum of two transitions; once to an "in progress" status and once to a "closed" status. So now you're up to a minimum of 3 rule executions per issue if you want those updates to occur in real time.

If you want to synch more than just the status that means more rule executions per issue. There is no single rule that will simply synch everything in a single executions.

If you are on a Standard plan for Jira Software, you will get 1700 rule executions per month. There is no option to increase your allowed monthly executions when you are on the Standard plan. If you hit your monthly limit rule executions will simply not happen for the remainder of the month.

You need to consider how many rule executions are likely to be happening to serve your requirement on a monthly basis, and how many other rule executions might be happening to serve other purposes. If you on the Premium plan then you get 1000 per licensed user, and then the limit may be so high that there is no issue.

Now, back to things to consider to actually implement the rules.

Are your other team's using Company Managed projects or Team Managed projects or some mix?

If they are all using Company Managed projects, are they using a common workflow? Your central project will have to use a workflow that encompasses all the status used in the workflows of the other teams' projects.

If the other teams are using Team Managed projects, that complicates the solution. Team Managed project statuses are "unique" even when they have names that are identical to the globally defined Statuses used in Company Managed project workflows. You would have to have a separate rule for each other teams' project when they are using Team Managed projects in order to map the statuses in that project to statuses used in your central project. And you would have to consider that the Project Admins on those projects could change the Statuses at any time.

You said you want the issue added to the central project to automatically generate an issue in the responsible team's project. How will you identify in which team's project that issue should be raised?

If you want the changes in the central project to happen in real time you will need to have rules that are triggered by changes in the other teams' projects. When one of those issues changes, the rule will need to know how to find the related issue in your central project. So, you will have to determine how you want to maintain the relationship between those two issues.

Generic issue linking is one method, and could be used in an automation rule to find the associated issue in the central project. However you have to consider if the source issue in the other team's project might be linked to multiple issues. And would it ever be linked to more than one issue in your central project? What would be the risk of some other user removing the link between that issue and the issue in the central project?

Maybe you want to consider not doing real-time updates, and instead doing a scheduled update. On some schedule run a rule that looks at all the issues of interest in your central project and looks for their associated issue in the other teams' projects. In that case, you might maintain the relationship by recording the other teams' issue key in a custom field in the central project issue, rather than using generic issue linking. Using a scheduled rule to update the central issues' status could also reduce your overall rule executions.

Another consideration is that you will have to create multi-project scoped rules. This will be required because your source issues (in the central project) will be in different projects than the destination issues (in the other teams' projects). If you set up the rule to be triggered based on a Status change, that would mean the rule would be triggered for status changes in all the projects referenced in the rule's scope. So you will also have to add a condition to your rule(s) that checks that the triggering issue is actual an issue in one of those destination projects.

Clara Belin-Brosseau_Elevatic

Hello @Mohammed A

If you're seeking for an easy way to synchronize issues and their workflows across projects, you can try our app Elements Copy & Sync. It allows you to clone and sync issues with all their content (summary, description, custom fields, comments, attachments, etc.) and their child issues.

You can have a look at the documentation here.

Don't hesitate to try the app, it's free during 30 days and stays free under 10 users.

Kind regards,
Clara

Katarzyna Szumilas_Deviniti_

Hi @Mohammed A

If you are open to using 3rd party apps you might want to check the Issue Sync Pro app which can address your problem by automatically synchronizing issues between a centralized project and various team-specific projects. Here’s how:

Centralized issue creation: Users from any department can create a bug issue in a single, centralized project.
Automated issue creation in team projects: When a new issue is created in the centralized project, Issue Sync Pro can automatically create a corresponding issue in the responsible team's project based on the conditions you have defined.
Bidirectional synchronization: Issue Sync Pro ensures that the two linked issues (in the centralized project and the team-specific project) are kept in sync throughout their lifecycle. This includes:
- Status updates: When the workflow status of the issue changes in one project, it is automatically updated in the other project.
- Field synchronization: The app can sync relevant system and custom fields
- Comments, attachments: Any updates, comments or attachments in one issue are mirrored in the corresponding issue.

If that sounds interesting do not hesitate to book a demo or test the app for free!
Best regards,
Kasia

Mathieu Lepoutre _Exalate_

Im working for Exalate.

Exalate is designed for this, to handle just the situation you've described. You can set up automated issue synchronization between different projects within the same Jira instance or across different instances. This allows bugs reported in the "master" project to be automatically replicated, and synchronized, in the relevant team's project.

Mohammed A_n6tncx

Hi @Trudy P Claspill ,

Sorry for the late response, I was in vacation for the last two weeks.

First, my plan is premium, so I don't have an issue with rule execution limits.

Second, our teams are using Company Managed projects and I will make the central project workflows same as the other teams' projects.

Regarding this question: "You said you want the issue added to the central project to automatically generate an issue in the responsible team's project. How will you identify in which team's project that issue should be raised?"

I think that can be easily done using post function in every issue type in the central project "when the issue created, create an issue in the required project"

Regarding the syncing and to make it less complicated, I want to sync only the status and resolution for the meantime.

Regarding this question: "And would it ever be linked to more than one issue in your central project?" the answer is No, every issue will be synced with only one issue.

Finally, I would highly appreciate it if you can explain to best way using the automation rules to sync the status and resolution step by step, which triggers to use, and which conditions ...etc.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud