nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Automation copy Comments

Federico Frade

I'm setting up an automation using Jira Automation to copy data from one work item to another. The trigger I'm using is "Issue assigned," and I've implemented it with a lookup to the new ticket and an "Edit Work Item Fields" action set to "Copy comments from trigger work item." The problem is that I'm getting this error: "We excluded the configured field from this action as it couldn't be found: Comments." Is there a way to force the trigger's comments to appear or become accessible?

Accepted answers

Lalithesh

Hi @Federico Frade

Welcome to the Atlassian Community!

The Comments actions are separate from the Edit Work Item action. To update fields such as Description and Priority, use the Edit Work Item action. To copy comments, add a separate Add Comment to Work Item action

Cheers!

Gor Greyan

Hi @Federico Frade

@Arkadiusz Wroblewski KB is the right direction here.

The important point is that Jira Automation can copy comments from one work item to another without using the REST API. Atlassian’s documented approach is to iterate through the source work item’s comments and add them individually to the destination work item.

In your rule, because the original work item is the one that triggered the automation, you can reference it with {{triggerIssue}} even while you are inside the branch for the destination Service Desk work item. Atlassian confirms that triggerIssue continues to point to the original triggering work item inside branches, and all normal issue properties are available on it.

So I would use an Advanced branch over:

{{triggerIssue.comments}}

Give the branch variable a name such as comment, then inside that branch add a Comment on work item action with something like:

Comment by {{comment.author.displayName}} on {{comment.created}}

The Comment on work item action supports smart values, so there is no need to fetch the comments via REST or convert ADF manually.

Sami Shaik

Hello @Federico Frade , you are one step from done, and the step has two versions depending on how exact you need the result. Credit where due: @Gor Greyan branch is the right iteration and @Lalithesh smart value is the right source, the remaining problem is only where the comments land, so let me close that gap.

Why your Lookup attempt failed first, because it explains both fixes: smart values like the lookup result do not reliably survive into an advanced branch's iterations. The reliable carrier is a variable created before the branch, variables persist everywhere in the rule, including inside branches.

Option 1, no web requests, and it matches what you actually asked for (author names included): post ONE comment on the destination containing every source comment, attributed and chronological, using smart-value list iteration instead of a branch:

In the rule, after your destination work item exists (your clone or lookup step), add a branch: For most recently created work item (or your destination branch)
Inside it, a single Comment on work item action with:

Comments copied from {{triggerIssue.key}}:

{{#triggerIssue.comments}}
{{author.displayName}} ({{created.format("dd MMM yyyy HH:mm")}}):
{{body}}
----
{{/}}

The {{#list}}...{{/}} iteration renders every comment with its author and timestamp. One comment on the destination, full attribution, zero API calls. This is the version I would ship for a migration flow.

Option 2, if it must be one destination comment per source comment: the wall you hit with ADF disappears when you use the v2 REST endpoint, which accepts plain text bodies:

Create variable before the branch: name destKey, value your destination key (from your lookup or created item)
Advanced branch over {{triggerIssue.comments}}, variable name comment
Inside the branch, Send web request: POST to /rest/api/2/issue/{{destKey}}/comment, JSON body:

{ "body": "Comment by {{comment.author.displayName}} on {{comment.created}}:\n{{comment.body.jsonEncode}}" }

(Authenticated with an API token via Basic auth headers.) Two caveats from real use: jsonEncode is not optional, the first comment containing a quote character will break the request without it, and advanced branch iterations are not guaranteed to run in order, which is why the timestamp prefix matters, the destination reads chronologically even if creation order shuffles.

Between the two: Option 1 is simpler, needs no credentials, and satisfies the attribution requirement you stated. Option 2 buys per-comment granularity at the cost of a web request and token management. Most teams that start with 2 end up at 1 🙂

All comments

Lalithesh

Hi @Federico Frade

Welcome to the Atlassian Community!

Cheers!

Arkadiusz Wroblewski

Hello @Federico Frade

What is the purpose of your solution and its use case? Depending on that, there can be a couple of solutions.

Best,

Arek 🤠

Federico Frade

Hi Lalitesh! Thanks for the reply and the welcome. I understand the proposed solution, but it has a limitation within the "Add comment on a work item" interface (which is the only one I see for this): there is no option to copy an existing message—and therefore neither copy all of them—a feature that is available (or so I understand) from the other screen.

Lalithesh

@Federico Frade You need to add a smart value to perform this action. For example, if you'd like to copy over all comments, add {{triggerIssue.comments}} smart value in the box

You can find more details about the smart values here - https://support.atlassian.com/cloud-automation/docs/smart-values-in-jira-automation/

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/

Screenshot 2026-08-14 144221.png

Arkadiusz Wroblewski

@Federico Frade

Here you have some example how it could work https://support.atlassian.com/jira/kb/copy-comments-from-the-original-jira-issue-to-a-cloned-issue/

Federico Frade

Here is some additional context regarding the use case:

I have a work item originating in a "common" space, and I want to automatically move it to a "Service Desk" space. That is the goal of this automation (what you are seeing is an isolated test of one part of the process).

To be more specific, the issue I haven't been able to resolve is copying comments from one work item to another—or, more precisely, copying the comment content itself (the original author isn't a priority for me).

I should also mention that I explored various combinations of GET requests to the messages and branches endpoints, as well as POST requests to the endpoint for creating work item messages, but I didn't achieve good results due to:
the automation limitation preventing iteration over fields in a `foreach` loop
the inability to access the comment as plain text (it always returns in ADF format)
the fact that the GET endpoint returns the data in a different format than what the POST endpoint expects

Arkadiusz Wroblewski

It was asked surprisingly often on the Community Forum.

For example, here you have one example of design. https://community.atlassian.com/forums/Jira-questions/JIRA-Automation-Clone-Issue-clone-comments-link-issues/qaq-p/2603347

Gor Greyan

Hi @Federico Frade

@Arkadiusz Wroblewski KB is the right direction here.

So I would use an Advanced branch over:

{{triggerIssue.comments}}

Give the branch variable a name such as comment, then inside that branch add a Comment on work item action with something like:

Comment by {{comment.author.displayName}} on {{comment.created}}

The Comment on work item action supports smart values, so there is no need to fetch the comments via REST or convert ADF manually.

Federico Frade

This works, even though it’s not exactly what I need; it combines all the comments into a single one, whereas I’d like to at least include the name of the person making each comment in the text.

Federico Frade

Ok so the solution you proposed works almost perfectly, but there’s a problem: it creates the comments on the trigger work item. I want to create them on a new one instead, so I tried using a "Look up work item" action, but it didn't work. I’m not sure if this is an Automation bug or if I’m misunderstanding how to use it. In the original workflow I shared, it selected the work item correctly—but I was using it to initialize branching there, which I can't do here because I'm using a `foreach` loop (and there's a limitation preventing nested branches).

Sami Shaik

In the rule, after your destination work item exists (your clone or lookup step), add a branch: For most recently created work item (or your destination branch)
Inside it, a single Comment on work item action with:

Comments copied from {{triggerIssue.key}}:

{{#triggerIssue.comments}}
{{author.displayName}} ({{created.format("dd MMM yyyy HH:mm")}}):
{{body}}
----
{{/}}

Option 2, if it must be one destination comment per source comment: the wall you hit with ADF disappears when you use the v2 REST endpoint, which accepts plain text bodies:

Create variable before the branch: name destKey, value your destination key (from your lookup or created item)
Advanced branch over {{triggerIssue.comments}}, variable name comment
Inside the branch, Send web request: POST to /rest/api/2/issue/{{destKey}}/comment, JSON body:

{ "body": "Comment by {{comment.author.displayName}} on {{comment.created}}:\n{{comment.body.jsonEncode}}" }

Federico Frade

Thanks, Sami; this was the missing piece. @Lalithesh answer had already gotten me very close, but since the values were being copied as concatenated body content, I hadn't thought to iterate through them (plus, I thought there was a limitation on doing this within Advanced Branches).
I applied these changes, and everything worked perfectly.
I'm attaching a screenshot of the final configuration in case anyone else comes across this thread later.

Thanks also to @Arkadiusz Wroblewski , @Gor Greyan and @Lalithesh ! for your answers there were really useful.

Sami Shaik

@Federico Frade wonderful, and thank you for coming back with the screenshot: that one image will save the next person with this rule an hour, which is worth more than any of our answers. Enjoy the clean comment history 🙂.

Gor Greyan

Hi @Federico Frade

Lookup work items only retrieves work items into {{lookupIssues}}; it does not change the current work item context. Therefore, when the Add comment action runs inside your Advanced branch over {{triggerIssue.comments}}, the action still targets the trigger work item.
Normally you could switch context using a Branch rule / related work items branch for the destination, but in your current design that would require a nested branch, which Jira Automation doesn't support. Since you already have each source comment available in the Advanced branch, one practical solution is to use Send web request inside that loop to POST each comment directly to the destination:
POST /rest/api/3/issue/{{destinationKey}}/comment
This is simpler than your previous REST approach: you don't need to GET the comments or convert the response first. The comment is already available through your branch variable; REST is only being used to write it to the correct destination work item.
So I don't think you're missing anything with Lookup work items, it can retrieve the destination, but it cannot make that work item the target of subsequent issue actions.

If the destination is a JSM request, also take care to preserve the intended public/internal comment visibility.

Evelin Bayer - codefortynine

Hi @Federico Frade - glad you found a working solution!

If you ever need to set up a similar flow again, it might be worth stepping back from the individual comment-copying problem for a moment. The root challenge here is really: move an issue from a standard Jira project into JSM - with everything intact. The comment transfer is just one piece of that.

Why the native approaches require so much effort

As this thread shows well, copying comments with Jira Automation involves several moving parts:

Using {{triggerIssue.comments}} directly dumps all comments into a single block - no per-author attribution, no timestamps, no individual entries
Iterating via Advanced Branch works, but requires creating a variable before the branch, careful scoping, and - as you pointed out yourself - nested branches aren't supported, so targeting a destination issue gets tricky
Going the REST API route means managing API tokens, handling ADF-to-plaintext conversion, and aligning GET response format with POST expectations

All solvable - this thread proves it - but it takes time and automation know-how to get right.

Deep Clone as a simpler alternative

If your original use case is moving or cloning an issue between projects (including from a standard Jira project into JSM, like yours) - and not copying comments from one work item to an existing work item - our Deep Clone app handles comment copying natively:

Comments are copied as individual entries, preserving author and timestamp
Works cross-project, including into JSM service desks
No automation rule, no smart values, no API tokens required
Configurable once - no per-rule maintenance
Of course, you can also just integrate Deep Clone as an automation action into your existing Jira automation

It won't replace automation for complex conditional workflows, but for the core use case of "clone an issue and bring the comments along," it's a straightforward option.

Disclosure: I work for codefortynine, the team behind Deep Clone.

Clara Belin-Brosseau_Elevatic

Hi @Federico Frade

Sounds like you managed to solve your problem!

One thing worth mentioning: if you ever need comments to be synchronized between tickets to avoid manual updates, that's where our app Elements Copy & Sync can help. Instead of only cloning comments and fields once, it can also keep them synchronized afterwards: so if a customer adds another comments or even a team member, everyone is updated on the ticket they're working on.

This is typically used by teams doing escalation between support and dev to avoid the back-and-forth of manually re-attaching or re-copying updates after the initial escalation. You can check the documentation if that's something that could be useful for your team.

Capture d’écran 2026-09-03 à 09.41.38.png

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

comment

jira-cloud

automation

copy

jira-automation