Merge duplicate requests into one main request.

The Service projects section lists every service project on the site, with Merging (On or Off), the Done status and the Resolution. Click Edit on a project:

• Agents can merge requests in this project turns merging on or off.
• Move the duplicate to this status: only statuses in the Done category of the project's workflows are listed. The agent who merges, and the app, which makes the change, both need a transition to it from the duplicate's status. You can't turn merging on without a done status.
• Resolution: a resolution, or Leave it to the workflow. A resolution can only be set if the Resolution field is on that transition's screen. If it isn't, the duplicate is closed without it and the merge says so.

The window shows who saved the project last. If a saved status or resolution has since left the project's workflows, the window says so and asks you to choose another.

On a request in a service project, open the ••• menu and choose Merge requests. The window asks What is SUP-1? (the request you are on):

• SUP-1 is the main request. Merge duplicates into it. The search lists open requests in the same project, and you tick the duplicates under Choose the duplicates. A duplicate must be open.
• SUP-1 is a duplicate. Merge it into another request. The search lists any request in the project, and you choose one under Choose the main request. A closed request can only be the main request.

Type a key or words from a request and click Search. The 20 newest matches are shown, and the window says when there are more. A request you chose before another search stays on the list. You can merge up to 10 duplicates at a time. Click Preview the merge.

If merging isn't turned on for the project, or no done status is set, the window says Merging is not set up here and names what a Jira admin needs to do.

1. Copying comments. Oldest first, after the main request's own comments. Each copy starts with a line such as Copied from SUP-2 · Written by [author] on 2026-11-02 10:04 UTC · public · Merged by [agent]. A comment keeps its public or internal setting and any role or group restriction. Mentions become plain text, so nobody is notified twice. An image embedded in a comment is replaced by a short note; the file itself is copied in the next step.
2. Copying files, up to the size limit, one at a time, if you can add attachments to the main request.
3. Adding request participants: the duplicate's reporter and its participants.
4. Adding organizations the main request doesn't have yet. Existing ones are kept.
5. Adding watchers, if you can see them and manage the main request's watchers.
6. Copying issue links, pointing the same way as on the duplicate, up to 100 per duplicate.
7. Linking as Duplicate: the duplicate "duplicates" the main request.
8. Copying comments added during the merge, in case a customer replied while files were copied.
9. Adding the merge notes: an internal note on the main request saying what was copied and naming any files not copied, and an internal note on the duplicate saying where it went. With tell customers on, the duplicate also gets a public comment telling its customers where their request went.
10. Closing the duplicate: moved to the chosen done status with a transition you can use, with the resolution if the transition screen allows it.

The merge runs in the background. The window shows the step it's on, and you can close it; the merge carries on. When it's done, the window says Merged and lists what was copied for each duplicate, what was not copied and why. Refresh the request to see the copies. Start another merge takes you back to the start.

Nothing is copied twice. Each copied comment carries a marker, and files already on the main request with the same name and size are skipped, so a merge that stopped and carried on, or a new merge after one that stopped, doesn't repeat anything.

Before the preview, at the start and on Try again, the app asks Jira, as the person on the page, whether they can:

• on the main request: be an agent of the service project, see it, edit it, add comments, link issues, and add attachments when there are files to copy;
• on each duplicate: be an agent of the service project, see it, edit it, add comments, link issues, and change its status.

A link that starts at an issue in another project is copied only if you can link issues in that project. Watchers are copied only if you can see them and manage the main request's watchers. Without permission to add attachments to the main request, a file added to a duplicate after you start is listed as not copied. Each duplicate is closed only with a transition you can use; the app never picks another one.

The changes themselves are made by the app in the background, so Jira's history shows the app as the author of the copies. Each copied comment and the notes on both requests name the agent who started the merge (or who last pressed Try again). The app's own access comes from Jira's atlassian-addons-project-access project role. If a project's permission scheme leaves that role out, or a workflow condition hides the done transition from the app, the merge stops at that step and leaves the duplicate open.

Only Jira administrators can open the settings page and the log. The app checks this on every request.

• One service project at a time. Requests are merged within one project only.
• No undo. The app can't undo a merge. The log and the notes on both requests say what was copied, so it can be undone by hand.
• Copied files are new uploads. They show the app and the merge date, not the original uploader and date. Files over the limit (25 MB at most, 10 MB unless you change it) are left out and listed.
• Not moved: satisfaction ratings, SLAs, time logged, history and approvals, web links and Confluence page links. Only links between Jira issues are copied.
• Comments the app can't read. A comment restricted to a role or group the app is not in can't be copied. The preview lists it, so you can copy it by hand.
• Customer emails. Jira can't add a public comment, add a participant or close a request without its own customer emails. The app tells you which ones to expect.
• Order and dates. Copied comments come after the main request's own comments. Each copy shows the original author and date (in UTC) on its first line.
• Turning merging off lets a merge already running finish. New merges and Try again are refused from then on.
• The request behind the window doesn't update itself. Refresh it to see the copies.