- Basics
-
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
- Synchronize with Jira Service Desk
- Configuration
- How-tos
-
Troubleshooting
- 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
- Administration
- Reference
-
FAQs
- 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
- 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
- Limit the synchronized issues
- Basic Authentication Change Notice
- Username Deprecation Notice
- Synchronization Message Flow
- Clear the sync info panel
- Change integration user to atlassian account
Create a synchronization
Backbone Issue Sync allows you to integrate two Jira projects to synchronize issues.
Scope of a synchronization
Synchronizations are always configured on a project-by-project basis, always between two projects.
However, you can create multiple synchronizations per project. So if you want to connect one project with multiple projects, you can simply create multiple synchronizations for a project.
Data transmission protocol
Backbone uses the official Jira REST API in order to access both Jira projects which it integrates. If you provide a HTTPS URL when you setup the synchronization, Backbone will use an encrypted channel in order to communicate with JIRA.
Configuration types
You can create new JIRA project synchronizations using two different configuration types – either distributed configurations or centralized configurations.
This article will explain which configuration type you should select depending on your use case.
Centralized configuration
You should use a centralized configuration if:
Your Jira can reach the other Jira directly via HTTPS or vice versa
- You want all administration tasks to be carried out in a single JIRA instance
- You have already successfully used the centralized method with a particular partner and want to use it again
If your requirements match these criteria, please create a centralized synchronization.
Distributed configuration
You should use a distributed configuration if:
- Both JIRA instances are behind a firewall and no Jira can connect to the other via HTTPS
- One or both project owners might want to hide JIRA config information (e.g. issue type/field/workflow status names) from the other
If your requirements match these criteria, please read more about distributed the distributed configuration and create a distributed synchronization.
In general, we recommend to use the centralized configuration since this is easier to administer.