In this article you can find more information on what is included and required in cloning with quick connect and what the current limitations are.
Want to learn more about what Quick Connect is? Read more about it here.
Supported Setups
Quick Connect clones spaces on Jira Cloud only. It’s currently not available with a remote license.
|
Setup |
Where you can clone |
|---|---|
|
Two spaces on the same Jira Cloud instance |
Both spaces |
|
Two spaces on different Jira Cloud instances |
Both spaces |
|
Jira Cloud to Jira Data Center |
The Cloud space only |
|
Jira Data Center to Jira Data Center |
Neither space |
Syncing Cloud with Data Center? Create the Data Center space in Jira first, then sync with it as an existing space.
Space types
Quick Connect supports company-managed spaces, including Jira Service Management spaces. The clone always matches the type of its source, so cloning a service space gives you a service space.
|
Space type |
Supported |
|---|---|
|
Company-managed |
Yes |
|
Jira Service Management |
Yes* |
|
Team-managed |
No** |
*Jira Service Management spaces are supported - however, the request types need to be configured
**Backbone can synchronize with a team-managed space, but it can't clone one. Therefore, you need to create the space in Jira first and sync with it as an existing space.
Cloning Is a One-Time Action
Backbone clones the configuration once, during setup. After that, it syncs work items only. That means that any workflow update, scheme changes or field/work items additions are not copied over.
Keep both configurations aligned yourself, or adjust the synchronization mapping when something changes.
What Quick Connect Clones
Backbone doesn't duplicate configuration unnecessarily. For each item it needs, it either creates a copy or points the new space at something that already exists.
Before the clone runs, you see a review step reporting three totals and for each item, whether it’s new, reused, a Jira default or skipped.
-
-
New: This item gets created on your instance because nothing like it exists yet. For example, the work type scheme doesn’t exist and will be created with the source name prefixed with "Clone of."
-
Reused: This item exists already on your instance, so it reuses that instead of creating a duplicate. For example, if the source space has a work type Bug and your instance as well, it reuses your existing Bug work type.
-
Jira default values: this item isn’t cloned from the source instance. It assigns your instance's existing Jira default. For example, the permission scheme always falls back to your instance's default, no matter what the source space has configured.
-
Skipped: Backbone Work Sync can't create this item on your instance, so it leaves it out. This usually happens with fields that belong to a third-party app that isn't installed on your instance.
-
A searchable list breaks the totals down. One row can show both, such as +1 new · 5 reused for work types. Expand a row to see the individual items and which ones are new, reused or skipped.
All new schemes will have the prefix “Clone of“ to easily find it back
The list covers these elements, in this order:
|
Configuration |
What is Cloned |
|---|---|
|
Work type scheme |
Created new |
|
Work types |
|
|
Field schemes |
Created new - only when new field schemes are available on both instances. |
|
Fields |
|
|
Workflow scheme |
Created new |
|
Workflows |
Created new |
|
Workflow statuses |
|
|
Priority scheme |
Created new |
|
Priorities |
|
|
Screen scheme |
Created new |
|
Screens |
Created new |
|
Screen tab |
Created new |
|
Work item security scheme |
Jira default is always used |
|
Permission scheme |
Jira default is always used |
|
Notification scheme |
Jira default is always used |
What Quick Connect Doesn't Clone
Quick Connect covers the configuration a synchronization depends on. The cloning doesn’t include:
-
Jira automation rules
-
Users, groups, and their memberships
-
Boards, filters, and dashboards
-
Data from other Jira apps
-
Work item history, such as status transitions and past field changes
Jira plans and work type hierarchy
Quick Connect works with any Jira Cloud plan, including Free. Be careful when the two instances run different plans, because plans differ in how many work type hierarchy levels they support.
Cloning between a Free and a Premium instance can produce unexpected results for work types. A work type above hierarchy level 0, such as an epic, can't keep its level on a plan without extra levels. Backbone Work Sync clones it at level 0 and warns you in the review step.
Work Items
Cloning work items is optional. Select Also clone [number] work items into the new space when you set up the clone. The label shows how many work items your space holds.
Quick Connect clones up to 100 work items per space. If your space holds more, Backbone clones the first 100 and will show this as a warning in the dialog.
Cloned work items keep their status. A work item that's In Progress in the source space arrives In Progress in the clone.
Backbone Work Sync copies these fields with each work item:
-
Summary
-
Description
-
Assignee
-
Reporter
-
Labels
-
Priority
-
Work item links
-
Comments
-
Attachments
-
Work logs
Need more than 100 work items in the new space? Clone the space without work items, then set the scope in the synchronization itself. See limit the synchronized work items.
Names and Keys
Backbone suggests a name and key for each cloned space, and you can change both. The receiving admin can also adjust them before accepting. Standard Jira rules apply:
-
The key must be unique within the instance.
-
The name must be unique within the instance.
-
The key has the same character limit as creating a space in Jira.
If Cloning Fails
If a clone doesn't finish, the progress dialog shows an error. Check the following:
-
Confirm you have permission to create spaces in the target instance.
-
Retry the clone.
Still stuck? Contact K15t support.