Connecting Another Jira Site (Cross-Site Clone) — User Guide

Overview

Bulk Clone Pro can clone Work Items into another Jira Cloud site, not just the one it is installed on. Before you can do that, an administrator connects the destination site once from the Connected Sites screen and authorizes access using OAuth — the same secure “Sign in with Atlassian” style consent you already use across Atlassian products.

You never type or store a password or API token. Authorization happens entirely through Atlassian’s own login and consent screen, and access can be revoked at any time.

Availability: Cross-site cloning is part of the Advanced edition. If you don’t see the Connected Sites screen or a destination picker in the clone wizard, your edition doesn’t include it.

How it works (in plain terms)

1. You add a connection that points at the destination site’s URL.
2. You click Authorize. Atlassian’s standard consent screen opens in a new tab.
3. You sign in (if needed) and approve the requested Jira permissions.
4. The tab closes automatically and the connection shows as Connected.
5. From then on, you can pick that site as the destination when you run a clone.

Behind the scenes, Bulk Clone uses OAuth to obtain a token that lets it create issues on the destination site on your behalf. The app requests only the Jira permissions it needs (reading and writing Jira work items and looking up users). It never sees or stores your Atlassian password.

Setting up a connection

1. Open Bulk Clone → Connected Sites.
2. Click Add connection.
3. Fill in:
   • Connection name — a label you’ll recognise (e.g. “Marketing Sandbox”).
   • Site URL — the destination site, e.g. https://your-company.atlassian.net.
4. Click Save. The connection appears as a card, not yet authorized.
5. Click Authorize on the card.
6. Complete the Atlassian consent screen in the tab that opens.
7. When it closes, the card updates to Connected / Authorized.

Tip: You must have access to the destination site with an account that can create issues there. Authorization is tied to your Atlassian account, so the clone will act with your permissions on the destination site.

Authorizing an existing connection

Each person who wants to clone into a shared connection authorizes it individually — authorization is per user, so seeing a connection in the list doesn’t mean you can use it yet.

If a connection shows Needs authorization for you:

1. Click Authorize on that connection’s card.
2. Complete the consent screen.
3. The card switches to Authorized once you’re done.

You’ll also be prompted to authorize if you pick a destination site in the clone wizard that you haven’t authorized yet — just follow the same Authorize step, then continue.

Using a connected site in a clone

1. Start a clone from Filters → Search for work items → Apps → Bulk Clone.
2. Step through the wizard to the Site step.
3. Choose the destination:
   • This site — the default, clones within the current site.
   • A connected site — pick one of your authorized connections.
4. On a cross-site clone, a unique label is required and generated for you. It’s how the app finds the cloned issues on the destination site afterwards (the destination site doesn’t have Bulk Clone installed, so the label is used instead of an internal session marker).
5. Finish the wizard and run the clone. When it completes, the Issues button opens the destination site filtered to the newly cloned issues by that label.

Cross-site clones support the same features as same-site clones — subtasks, attachments, comments, issue links, reporter/assignee, and custom-field mapping — with one difference: because sites don’t share IDs, you map custom fields and their values to the destination site’s equivalents during setup. See the field-mapping step in the wizard for details.

Field and user mapping across sites

Different Jira sites use different internal IDs, so the app remaps values as it clones:

• Custom fields — you map each source field to a field on the destination site. If a field has options (dropdowns, checkboxes, etc.), the app matches options by name, and you can override any mapping manually.
• Users (reporter/assignee) — matched to the same person on the destination site where possible. This only succeeds if that person has access to the destination site.
• Links to the source — because native issue links can’t span sites, the app adds a remote link on both the original and the clone so you can navigate between them.

Revoking access

You can revoke your authorization at any time:

1. Open Connected Sites.
2. On the connection, choose Revoke my access.
3. Your token is removed and the connection shows Needs authorization for you again.

Revoking affects only your access to that connection; other authorized users are unaffected. If a connection’s authorization later expires or is revoked at the Atlassian level, the app will prompt you to re-authorize the next time it’s needed.

What is (and isn’t) stored

• Not stored: your Atlassian password, and no API tokens.
• Stored securely (encrypted): the OAuth tokens the app needs to write to the destination site on your behalf. These are never shown in the browser and are only used by the clone engine.
• The connection card only ever displays non-sensitive details — the name, the site URL, and whether you’re authorized.

Troubleshooting

What you see	What it means	What to do
Card stays Needs authorization after consent	The authorization didn’t complete, or you cancelled the consent screen	Click Authorize again and finish the Atlassian consent screen.
“The authorizing account can’t access this site”	The account you signed in with doesn’t have access to the destination site	Authorize with an account that can access the site, or fix the site URL.
A clone into a connected site is blocked before it starts	You (or the automation actor) haven’t authorized that connection	Open Connected Sites and click Authorize, then retry.
Connection worked before but now asks you to re-authorize	The stored authorization expired or was revoked	Click Authorize again to reconnect.

FAQ

Do I need to create anything in the Atlassian developer console? No. Connecting a site is just adding the URL and clicking Authorize. There’s nothing to register.

Does each teammate need to authorize separately? Yes. Authorization is per user, so everyone who clones into a shared connection authorizes it once.

Can I clone into a site in a different Atlassian organization? Yes, as long as you sign in during authorization with an account that has access to that site and can create issues there.

Is my password shared with the app? No. You sign in on Atlassian’s own screen; the app only receives a permission-scoped token, never your password.