Jira Cloud: How to Copy Individual Public Comments from JSM Ticket to Linked Jira Software Ticket

[Kent G]

Environment

• Jira Cloud
• Jira Service Management source project
• Jira Software destination project

What I'm Trying to Accomplish

I have an automation rule that fires when a JSM ticket transitions to a specific status. The rule creates a new linked Jira Software ticket in a separate project. When the new ticket is created, I need all public (non-internal) comments from the JSM source ticket copied to the newly created Jira Software ticket as individual comments - one comment on the destination ticket per original comment on the source ticket. Each copied comment should include the original author's name and the date it was originally posted.

To be clear: a single consolidated comment containing all the original comments lumped together does not meet the requirement. Each comment must be posted as its own discrete comment on the destination ticket.

The Question

What are my options for accomplishing this in Jira Cloud? Has anyone successfully implemented something like this?

For disclosure: I've built a solution that *almost* works but not quite. I'm fully up for disclosing what it is, but I'd rather have suggestions that aren't tainted by me leading the witness.

A solution that uses only native Jira functionality is preferred, but I do have Scriptrunner for Cloud in my instance, so it is on the table as an option.

[Kent G · Accepted solution]

I got this working with a couple small caveats. I wrote the instructions as a Confluence page and a PDF, but I don't think I can attach that here. Here are the screenshots.

[Derek Fields _RightStar_]

If you want to copy the public comments from the JSM ticket to the Jira work item, you can do this by creating a branch on the comments in the JSM ticket and creating a new comment on the linked ticket for each internal comment that you find. 

However, the trick is that since you can't directly create the comment on the linked ticket, you need to create a second automation as a webhook that takes the comment body from the first automation and the original issue key. The second automation (the webhook) has a branch on all tickets linked to the JSM ticket with whatever other conditions you may need. It then creates the comment from the passed comment body in the linked ticket.

I know this is pretty high-level. If you need more detailed instructions, let me know. I am at Team '26 right now, so it may take me a few hours to get back to you with screenshots.

[Kent G]

@Derek Fields _RightStar_ This makes perfect sense as it is the path I have been going down. What is happening though, is this -- if there are 4 comments on the JSM ticket, then four comments get written to the Jira Software ticket but they all say this:

"Comment added by Kent G on 5/1. Comment body:"

"Comment added by Kent G on 5/2. Comment body:"

"Comment added by Kent G on 5/3. Comment body:"

"Comment added by Kent G on 5/4. Comment body:"

In other words, a comment is added to the Jira Software ticket, but the comment body is always coming over blank.

I have been using Claude to troubleshoot, and here is how it has diagnosed the problem:

"The One Remaining Blocker: {{comment.body}} resolves to an ADF JSON object, not a plain text string. Every variation we tried — {{comment.body.text}}, {{comment.body.plain}}, {{comment.body.renderedBody}}, {{comment.body.content[0].content[0].text}}, {{comment.body.content.0.content.0.text}} — either broke the JSON payload (400 error) or resolved to empty. The v2 API with a plain string body also failed."

The approach you mention is very valid and it is the desired solution. I haven't abandoned it yet. But I have not yet hit upon a value that writes the comment body successfully.

[Derek Fields _RightStar_]

Can you show me what you are passing in the body to the webhook that adds the comment? When I do it, I get the text of the comment. 

You should be setting up your branch like this:

Then you should pass {{comment.body}} in your JSON payload to the webhook. So your JSON payload might look something like this:

{
  "comment":"{{comment.body}}",
  "author":"{{comment.author.displayName}},
  "date":"{{comment.created}}"
}

In the webhook, you would might format the comment as

{{webhookData.author}} created comment at {{webhookData.date}}:

{{webhookData.comment}}

[Kent G]

The way I have it set up now is, in automation 1:

Then in automation 2:

I believe this is something a little different than what you suggested. I'll need to wrap my head around how to update in the way you suggested.

Where it says "comment.body.plain" I have tried a lot of other things -- {{comment.body}}, {{comment.body.text}}, {{comment.body.plain}}, {{comment.body.renderedBody}}, {{comment.body.content[0].content[0].text}}, {{comment.body.content.0.content.0.text}}

...et cetera, but none have worked so far.

[Kent G]

@Derek Fields _RightStar_ 

I may have just gotten this working. I will be doing some heavy testing tomorrow and I'll reply back with the results.

Thanks for the input, and if it works, I'll let you know how.

[Kent G]

I posted what ended up working as a separate comment to this thread. @Derek Fields _RightStar_ -- I too went about this with 2 different automations, one triggers the other, but I think the way I did it came at it from a different angle than you were going. In any case, it is working now and thanks for the input!

[Bill Sheboy]

Hi @Kent G 

If you want this going forward, please try:

• an automation rule with multiple-project scope,
• triggered on adding comments, 
• using a condition to check the comment was added to your JSM project's item
• using a condition to check the comment is public (i.e., not internal)
• and then branch to the desired linked work item to add the comment, using the trigger data as the source

If you want this for existing work items and comments, you may want to investigate marketplace apps to help.

Kind regards,
Bill

[Kent G]

This particular use case is: "At the point the JSM ticket goes into a certain status, create a new ticket, and copy all the previously existing public comments to the JSM ticket to the newly created ticket."

The use case for: Adding new public comments one-by-one as they get added -- is already in place via an automation.

Paying for an addon is not necessarily off the table, but any increase in subscription cost needs to be justified, whereas a solution using native functionality, Scriptrunner, Forge, etc. does not. 

[Bill Sheboy]

One challenge for automation rule iteration through existing comments (filtered on the ones which are not internal) is branching limits and the number of comments.  That is, there may be more comments than the limit, and so all are not copied.  There are risky workarounds using rule recursion, but they can be brittle and subject to other automation service limits.

When you expect the total number of comments (i.e., public and internal) to be fewer than 100 items, you could using a two rule approach:

• first rule (for the scenario you described with the scenario), creates the work item in the software project and links to it
• second rule, triggered on software project, work item created, with "Allow Rule Trigger..." enabled so the first rule's actions trigger the second, uses:
  • either Lookup Work Item data with JQL or a REST API call with Send Web Request to get the comments from the source JSM item
  • branch over the comments only, filters with a condition check on internal, and adds them to the trigger issue