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
- Start and stop synchronizations
- 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
- 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?
- Knowledge Base
Intro to Distributed Configurations
In distributed configurations, the configuration for an synchronization between two partners is divided into two synchronization configurations – one at each partner.
Master and slave concept
One synchronization is configured as the master, and the other is configured as the slave. The master is the synchronization partner that defines the terms of the synchronization, the slave works within these terms.
In more detail, the master synchronization partner decides which issue types and fields are exchanged between the projects. It is also able to activate comment or attachment synchronization. The slave cannot create or delete mappings. However, the slave can still define what it shares, but only within the scope of the mappings defined by the master.
Both these roles must be fulfilled – it is not possible to have two partners configured as slaves, or two configured as masters. Before creating the synchronization, you should discuss with your synchronization partner about which side should be configured as the master, and which should be configured as the slave.
Once you have decided which synchronization partners are to be the master and the slave, you can start creating the synchronization. The slave can only create its side of the synchronization after the master has created its side.
After creating the synchronization, the master can start to configure the synchronization in detail by defining issue type & field mappings and how comments, attachments or workflow information should get synchronized.
After the master has made all its changes to the synchronization, it can publish it. When publishing, it must leave a message for the synchronization partner informing them of the changes you have made. It's important to make this comment informative, so the process is as clear as possible for your synchronization partner.
Backbone will then send a message to the slave including the updated configuration. The slave will not receive the actual field or issue type names - so your information stays private all the time.
As soon as the slave receives the message, the slave synchronization will have the ‘update required’ status. This means that the master has updated its configuration and that the slave has not yet configured them on its side. In order to apply the new changes the slave has to complete the new configuration at its side by editing the configuration. On the import screen, it will receive the message that the synchronization partner wrote when publishing its changes. The message should make it clear what changes they made.
When the slave has completed its part of the configuration, it can itself publish its changes and start their part of the synchronization. Backbone will send a confirmation back to the master that the slave completed its synchronization allowing to start the synchronization at the master's side as well.