Jira Automation: Cloned ticket sets "Automation for Jira" Reporter instead of Org User

[Saif Wahab]

Hi everyone,

I’m currently setting up an automation rule to clone/create a ticket in a different Jira portal (project) based on a trigger in the source project.

The cloning logic is working perfectly, but I’m hitting a wall with the Reporter field. Every time the new ticket is created, the Reporter is set to "Automation for Jira" instead of the person who reported the original trigger issue.

What I've tried/noted:

• The cloning action is functioning and moving data correctly.

• I am looking for the best way to map the {{issue.reporter.accountId}} so it carries over to the new project.

My questions:

1. What is the most reliable Smart Value or JSON block to ensure the original reporter is preserved during the move?

2. Does the original reporter need specific permissions in the target project for this to work?

3. Are there any known limitations when cloning tickets across different service portals?

Looking forward to your insights!

[Peter_DevSamurai]

Hi @Saif Wahab , 

Rules run as the "Automation for Jira" system user, so the reporter defaults to that unless overridden. It's fixable with advanced JSON editing in the "Edit issue" action. 

Question 1: What is the most reliable Smart Value or JSON block to ensure the original reporter is preserved during the move?

• In the Action: Edit issue (on the new ticket).
• Fields: Choose "Reporter" (if visible) or use More options > Additional fields (JSON):

  • {"fields": {
       "reporter": {
            "accountId": "{{triggerIssue.reporter.accountId}}"}}}

• Note: Use {{triggerIssue.reporter.accountId}} if cloning from a trigger (original issue); swap to {{issue.reporter.accountId}} if in the same rule flow. This should set the reporter to the original user.
  
  

Question 2: Does the original reporter need specific permissions in the target project for this to work?

Yes, the original reporter must have:

• "Browse Projects" in the target project (to be visible).
• "Create Issues" isn't required, but if they need to interact (e.g., comment), add "Add Comments".
• As admin, check Project settings > Permissions > Ensure the reporter (or their group) has these. If not, the set fails silently (reporter stays "Automation").

Question 3: Are there any known limitations when cloning tickets across different service portals?

• Cross-Project: Works fine, but permissions (as above) and field contexts must match (e.g., reporter field available).
• Reporter Override: This one is only possible via JSON. UI picker won't let you select externals without permissions.
• Portals (JSM): If target is JSM, reporter becomes a "customer" if not internal -> use "Request participants" field for CC-like access instead.
• Limits: Automation runs/month unlimited in Premium, but watch for rate limits on cross-project actions (this is rare :)).

You should test in a sandbox rule: create a trigger ticket, clone, edit reporter JSON. If fails (e.g., 403 in audit log), it's probably permissions issue.

Happy New Year and I hope everything works out well for you!

Best regards, 

Peter

[Clara Belin-Brosseau_Elements]

Hi @Saif Wahab

As an alternative solution to Automation that can be quite complex and limited in terms of number of executions, I can suggest trying our app Elements Copy & Sync.
It will allow you to clone issues across projects based on triggers and to map fields such as the reporter field.

A practical setup:

1. Create a recipe: define your source and target projects

2. In the content tab, Field mappings options, ensure Reporter is copied (or mapped as needed).

3. Choose a trigger (manual / post-function / automation-triggered flow depending on your process) so the copy happens when the source ticket is created/transitioned.

You can check the detailed documentation here.

The app allows you to perform cloning without limitations nor technical skills and JSON.

It's free during 30 days (and it stays free under 10 users) so don’t hesitate to try it on your use case.