Example Use Cases
- Bidirectional synchronization
- Unidirectional synchronization
- Synchronize Jira Server with Jira Cloud
- Synchronize one project with multiple others
- Synchronize a private with a public project
- Synchronize projects behind firewalls
- Synchronize without installing
- Synchronize with changing Jiras
- Migrate Jira projects
- JIRA Service Desk
- Configuring the synchronization user
- Manage synchronizations (start/stop/configure etc.)
- Create a synchronization
- Issue Type Mappings
- Field Mappings
- Fields (Default values)
- Workflow Mappings
- Advanced Settings
- Configure email error notifications
- Distributed configuration
- Analyze and fix errors
- Trigger a resync
- Increase the JIRA logging level
Fix common problems
General problem situations
- 411 - Length required
- All fields have English names although Jira is in a different language
- Authentication with an external Jira fails
- Exception: ServiceLocatorImpl has been shut down
- Sync info panel displays wrong synchronization name, and no link to partner project
- Server is not reachable - how to fix it
- Changes are not being synchronized
- Can't change the synchronization user
- Recently created issue types, fields, etc. are not available when editing configuration
Issue specific problem situations
- Admin or project admin permissions are required
- Bad gateway
- Cannot add or remove watcher
- Cannot create new issue without mapped issue type
- Cannot find transition
- Cannot find transition id
- Cannot perform transition
- Component(s) not valid
- Could not resolve value of Project Key
- Fallback user does not exist
- Field not on the Screen
- Incoming Issue Error
- Incompatible message format
- Invalid JQL Filter
- Invalid license
- Invalid regex syntax
- Issue does not exist
- Issues must be assigned
- JIRA is offline
- Missing attachment permissions
- Missing Issue
- Missing issue type mapping
- Missing message
- Missing parent Issue error
- Missing required fields
- No create version permissions
- No project administration permissions
- Option not valid
- Outgoing Issue error
- Outgoing Send Error
- Priority not valid
- Resolution cannot be chosen
- Security level name is not valid
- Sprint does not exist
- Template error
- The requested board cannot be viewed
- User does not exist
- User not assignable
- Version(s) not valid
- Workflow operation not valid
- General problem situations
- Field mapping reference
- REST API
- Synchronization behavior
- Data Encryption
- Handling Personal Data
- How does Backbone affect server performance?
- Do you plan to synchronize with other systems?
- Does Backbone communicate via an encrypted channel?
- Can I synchronize an instance from behind an enterprise firewall?
- Can I synchronize an instance without installing Backbone?
- Can I have the same issue keys in both projects?
- Add a 'sync issue' button to the view issue screen
- Configure only changes made by one synchronization partner to be synchronized
- Rename the project key
- Stop synchronizations when Backbone is restarted
- Basic Authentication Change Notice
- Clear the sync info panel
- Change integration user to atlassian account
Synchronize a private with a public project
This use case describes how you can share information from your restricted (private) Jira project with viewers who don't have permissions to access it. This is done by creating another Jira project which the desired people can access and set up a synchronization between them. This can be helpful when you:
- Work in a Jira instance which is not accessible to your viewers.
- You can use a Jira Cloud instance and use Backbone to synchronize the information to it.
- You can set up a separate Jira instance in a DMZ and use Backbone to synchronize the information to it.
- Work in a Jira instance which is accessible to your viewers.
- You can use Backbone to create a view of your project with the information you want to expose.
Backbone enables you to create a "public view" on your project. You can configure exactly which fields or issues you want to expose; no need to mess around with issue security schemes. You can use another workflow for the public project and hide some statuses of your complex workflow. So in the end, your viewers get the information they need, and no more.
With this approach, you will end up with two Jira projects connected via Backbone. For every project, you have Jira's full flexibility of administration, e.g. for the fields or workflows. This guide assumes that you already have a project with all your details (let's call it private project).
- Create another Jira project (let's call it public project) which you will share with the people outside your private project. Administer the fields, workflows and permissions to suit your needs.
- If you have a complex workflow in the private project, think about using a simplified workflow for the public project.
- Create a new synchronization between your private and public project.
- Configure the issue types and fields you want to exchange between the projects.
- If the public project exists only for viewing information, you can create unidirectional mappings so information only synchronizes from the private to the public project, and not back.
- Configure your workflow mappings. If you used a simplified workflow in the public project, you can now define how your internal states match your simplified workflow.
Congratulations! The basic configuration is now complete.
Good to know
- If your Jira instance is accessible to the people outside your project, you can have both projects in the same Jira instance. Then you also only need one Backbone license.
- If you don't want to synchronize all comments from your private project to the public project, you could either synchronize comments only from the public to the private project or use comment restrictions.
- We are using this approach for our own product development, you can browse Backbone's public project to see how a public view could look.