Scroll Apps for Confluence
Backbone Issue Sync for Jira
AI-Powered Search for Scroll Viewport
About Us
Careers
Partner Program
Trust Center
Contact
Collaboration Hub
PDF Template Library
3 Ways to Extend Your Jira Workflows with Issue Synchronization
As I'm sure you're aware, Jira workflows are hugely flexible – with enough configuration options to cover the vast majority of use cases. But occasionally, they just can't do what you need them to do.
For example, it's not possible to:
-
Have different workflows
for logged-in users and external watchers
Make it possible for your users to
transition issues in a collaborator's Jira
without painful manual workarounds
-
Hide certain statuses
from people with access to your issues
If you've ever needed to do one of these, you'll be only too aware of the pain points involved. But don't despair – project-to-project Jira issue synchronization makes these scenarios possible, with the help of Atlassian Marketplace apps like Backbone Issue Sync for Jira. Here's how.
Scenario 1: Separate Public and Private Workflows
Description
You are working on an issue in your internal Jira project, and you are using a complex workflow with many states. The project is public, and you have a lot of people watching your issues for status updates.
However, external watchers are complaining because they are getting notifications about updates they can't understand, because your internal status names are meaningless to them.
Your aim
You want to keep your complex workflow because your processes require it – but also provide your watchers with workflow update notifications they can actually understand.
How issue synchronization makes it possible
Instead of having just one project for everyone, you have two separate, synchronized projects – one for internal users, and another for your watchers. The internal project is hidden to anonymous users, and your external project is publicly visible:
Now, because you have different projects, you can have different workflows too. In your internal project, carry on using a workflow as complex as you'd like: in this case we have 5 states – TRIAGE , OPEN , IN PROGRESS , IN REVIEW and DONE .
In the external project, however, use a simple workflow with only two steps: OPEN and DONE . Now you spare your customers from getting unwanted notifications, and only tell them what they really want to know – that the feature they have been waiting for is ready.
Scenario 2: Transition Issues in a Collaborator's Jira
Description
You are working on a project with a partner organization, who are tracking all the issues in their Jira instance. When you've finished working on an issue, you want to transition their workflow directly, so they can move forward.
However, this is an arduous task, no matter which method you use:
inform the partner via email, and get them to transition the state themselves (time-consuming and error-prone)
log into their Jira and transition the state yourself (problematic from a security and privacy standpoint)
Your aim
To be able to collaborate on collaborators' issues as if they were in your own Jira, and make workflow changes directly in your own instance.
How issue synchronization makes it possible
Issue synchronization can totally cure this pain point. Simply synchronize the issues you are collaborating on between your own Jira instance and your partner's. This lets you and your partner both make changes to issues just as if they were in your own instance.
All you have to do is configure workflow synchronization 1:1 between you and your partner's instances:
Now, whenever you trigger a workflow change in the synchronized issue in your instance, the same workflow transition will be automatically triggered in the partner instance. Problem solved!
Scenario 3: Hide Statuses from Your Collaborators
Description
You are working on an issue with a partner – but you don't want them to see all the statuses in your workflow, for whatever reason. However, you can't give the partner access to your issues without revealing all workflow states.
Your aim
Give your collaborator access to issues, but hide certain workflow states.
How issue synchronization makes it possible
If you use Backbone Issue Sync for Jira to synchronize issues between Jira Server systems, it's possible to sync workflow states without revealing their names to your partner. All you have to provide is the ID of that state, and a hint for your partner, so they can understand how to map this status on their workflow:
All your collaborator gets is a number, and a hint. You never have to share the names of workflow states that should remain private.
Interested? Try It for Free
If any of these scenarios sound interesting to you, you can try them out using Backbone Issue Sync for Jira. Workflow synchronization is available in Backbone for Jira Cloud and Jira Server.
