Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Automation rule not copying custom field values from linked issue

Sebastian Santoyo
Contributor
July 12, 2025

Hello community,

I'm trying to set up an automation rule so that when a Task (red) is created, it automatically copies specific field values from the related Requirement (green).

đź”§ Current setup:

  • Trigger: Work item created

  • Then a condition: Request Type = Tarea SC

  • After that, I use a Branch rule with a JQL query to find the related Requirement (via the "is blocked by" link type).

  • Inside the branch, I use an Edit work item action to copy values from several custom fields.

âś… Expected behavior:

When the Task is created, the following fields should be automatically filled with values from the Requirement:

  • Nombre de Requerimiento

  • Frecuencia del Requerimiento

  • VĂ­a de Entrega del Requerimiento

❌ Actual result:

These fields remain empty. They show up as “None”.

📎 Evidence attached:

  • A screenshot of the Task showing the empty fields

Screenshot 2025-07-12 at 10.26.42 p.m..png

  • A screenshot of the linked Requirement, where the fields are properly filled

Screenshot 2025-07-12 at 10.23.55 p.m..png

🤔 My question:

Am I missing something in the rule logic?
Is it possible that the way I'm referencing the linked issue's fields is incorrect?

Any guidance or suggestions would be greatly appreciated.

the JQL that is not working apparently:
issue in linkedIssues({{issue.key}}, "is blocked by") AND "Request Type" = "Requerimiento SC"

Screenshot 2025-07-11 at 5.00.28 p.m..png

Screenshot 2025-07-11 at 5.00.48 p.m..png

 

 


👉 Final note: The automation doesn't necessarily have to follow this exact sequence of steps. My main goal is for the “copy” fields in the Task to inherit the values from the original fields in the linked Requirement.
If anyone suggests a simpler or more effective approach, I’d be happy to consider it.

2 answers

1 accepted

1 vote
Answer accepted
Trudy Claspill
Community Champion
July 13, 2025

@Sebastian Santoyo 

This topic appears to be a duplicate of the one you already started here

https://community.atlassian.com/forums/Jira-Service-Management/Linked-Issues-Create-Queue-or-report/qaq-p/3064240

I will stop responding on that Question and start contributing here. In the future it would be better if you did not make multiple Question posts for your topic as it makes it more challenging for the responders to build off of each others replies.

Here is my reply copied from the other post:

 

Hello @Sebastian Santoyo 

As I mentioned in my previous reply, please show us the output in the Audit Log for the rule. That will provide critical information needed to debug your issue.

  1. Can you confirm that the rule is triggered by creation of the RED issue (Tarea SC)?
  2. Is the JQL you have specified attempting to retrieve the GREEN issues (Requirements) linked to the RED issue?
  3. Can you provide a table that shows the field names in the GREEN issue paired with the field names in the RED issue to show which fields you are trying to copy data from and to? In that table also specify the Field Type of each field. Example
Green Field  Green Field Type  Red Field  Red Field Type 
Frecuencia  Single Select List  Frequencia de Requerimiento  Single Select List

4. Are you trying to do a straight copy of data? If so, what do you expect to happen if the linked issues have different values from each other?

 

If the answers to 1 and 2 are "Yes" then your rule is not structured correctly.

When you use a BRANCH (For Each) component and nest actions under it, as you have done with the Edit action, the nested actions are taken against the issues you selected in the BRANCH, not the issue that triggered the rule. So, the Edit action is trying to edit the issues found by the JQL.

Additionally you tried to use the smart value {{lookupIssues}} in the branch to get the value you want to copy. The {{lookupIssues}} smart value is only populated when you use a Lookup Work Items action, which you have not done.

 

When you more fully describe the details of the fields and scenarios I will be able to offer you more specific guidance.

Sebastian Santoyo
Contributor
July 14, 2025

Hi Trudy, thank you very much for the detailed explanation. You're absolutely right — I’ll keep all discussion on this post going forward.

Let me answer your questions below:

1. Yes, the rule is triggered by the creation of a RED issue (Tarea SC).

2. Yes, the JQL inside the branch is trying to retrieve the linked GREEN issue (Requerimiento SC) using the "is blocked by" relationship.

3. Here is the table showing the source and destination fields:

 

Screenshot 2025-07-14 at 2.34.39 p.m..png

 

4. Yes, I'm trying to do a straight copy of data. At the moment, I expect only one linked Requirement per Task, so no conflicting values.

Please let me know how you recommend me to proceed.

Thanks again for your help and patience!

 

Trudy Claspill
Community Champion
July 14, 2025

Hello @Sebastian Santoyo 

Thank you for that additional information.

Can you confirm that you are linking the Requirement to the Tarea SC item within the Create dialog when creating the Tarea SC item? Or might you link the Requirement to the Tarea SC at a later time?

Here are my recommendations, assuming you are linking the two issues together within the Create dialog when creating the Tarea SC item.

With the Work Item Created trigger you can add directly to the trigger a check for the type of issue created and confirm that when it is created it has been linked to at least one other issue using a specified link type.

Screenshot 2025-07-14 at 1.15.50 PM.png

Next you would use the Lookup Work Items action to lookup the linked work items. Use the JQL you have already defined.

Screenshot 2025-07-14 at 1.21.52 PM.png

Add a condition to confirm that the Lookup action found exactly one item.

Screenshot 2025-07-14 at 1.41.33 PM.png

Use the Edit action to edit the issue that triggered the rule. 

Select each of the fields you want to set. (I'm using a field name "Custom Short Text").

Screenshot 2025-07-14 at 1.26.35 PM.png

 

Into each field you want to copy information from a different field from the issue found in the Lookup action. We've already confirmed there is only one issue in the results of the Lookup action, so you can use "first" to reference that first/only issue within the results.

Screenshot 2025-07-14 at 1.55.49 PM.png

Do the same for each field, setting the value to {{lookupIssues.first.<name of field in green issue>}}

 

 

Note: If you needed to copy data from more than one linked issue, the rule would have to be different.

Sebastian Santoyo
Contributor
July 14, 2025

Thanks Trudy, I did an effort to follow every step but could not automate copying the values from "Summary" (Green original) to "Nombre del Requerimiento" (Red New)

Jira emailed me this error:

Work item created
07/14/2025, 16:31:15

Lookup work items
07/14/2025, 16:31:16

Unable to run the search while custom values were being defined: .
Custom Smart Value JQL Search: "(linkedIssues("V4-91", "is blocked by") AND type = Sub-task) AND (project in (10099))" - Error in the JQL Query: Expecting operator but got '('. The valid operators are '=', '!=', '<', '>', '<=', '>=', '~', '!~', 'IN', 'NOT IN', 'IS' and 'IS NOT'. (line 1, character 14)
{{smart values}} condition
07/14/2025, 16:31:16

 

 

-It is necessary to link the Requirement to the Tarea SC item within the Create dialog when creating the Tarea SC item. Not possible to link the Requirement to the Tarea SC at a later time.

 

Let me show you what I did, so you can tell me if there is some mistake.

1. Trigger

Screenshot 2025-07-14 at 4.46.15 p.m..png

2. Lookup work items

 

Screenshot 2025-07-14 at 4.47.39 p.m..png

issue in linkedIssues[{{triggerIssue.key}}, "is blocked by"] AND type=Sub-task

 

3. compare condition

Screenshot 2025-07-14 at 4.48.56 p.m..png

 

4. edit work item fields (by now only Summary (Green) vs Nombre del Requerimiento (Red)

Screenshot 2025-07-14 at 4.50.30 p.m..png

 

 

Note: No need to copy data from more than one linked issue, only one.

 

 

Trudy Claspill
Community Champion
July 14, 2025

Hello Sebastian,

You almost have it.

In step 2, the Lookup step, you need to use your JQL, not my JQL. In my JQL I used Sub-task for the type of item that would be linked. As you've mentioned in your post you are using Requerimiento as the type of item that is linked.

Additionally you have added square brackets around the parameters for linkedIssues. Those need to be parentheses.

I used "triggerIssue.key" rather than "issue.key" because "triggerIssue" is an explicit reference to the issue that triggered the rule. "issue" refers to the issue in context, and changes when you are using branches. I think it is a good practice to use "triggerIssue" when you definitely want to refer to the trigger issue. 

issue in linkedIssues({{triggerIssue.key}},"is blocked by") and type=Requerimiento
Sebastian Santoyo
Contributor
July 14, 2025

Finally I could with some help from a workmate!

 

Let be share it with you and the Jira SM community some key elements!

1. The trigger, thanks to you Trudy

Screenshot 2025-07-14 at 9.02.48 p.m..png

 

2. the Lookup you gave me with a minor adjustment

Screenshot 2025-07-14 at 9.04.24 p.m..png

JQL:

issue in linkedIssues({{triggerIssue.key}}, "is blocked by")

 

3. Branch rule / current work item

Screenshot 2025-07-14 at 9.06.26 p.m..png

 

4.1 create variable summary

Screenshot 2025-07-14 at 9.07.48 p.m..png

Variable name* (required): itemReq
Smart value* (required): {{lookupIssues.first.summary}}

 

4.2 same for the other variables

Screenshot 2025-07-14 at 9.09.25 p.m..png

Variable name* (required): itemFrecuenciaReq
Smart value* (required): {{lookupIssues.first.Frecuencia}}

 

(disregard this email, was just to do some validations)

 

Screenshot 2025-07-14 at 9.11.39 p.m..png

5. The Edit work item fields to modify the values of the fields in the new issue inheriting the values of the fields in the original issue

 

Nombre de Requerimiento: {{itemReq}}
Frecuencia del Requerimiento: {{itemFrecuenciaReq}}

Screenshot 2025-07-14 at 9.16.13 p.m..png

Screenshot 2025-07-14 at 9.17.01 p.m..png

 

Result? SUCCESS FULL AUTOMATION

These were the original "GREEN" values

Screenshot 2025-07-14 at 9.19.43 p.m..png

These are the replicated copied "RED" values

Screenshot 2025-07-14 at 9.22.30 p.m..png

Thank you so much Trudy!!!

Like • Trudy Claspill likes this
3 votes
Walter Buggenhout
Community Champion
July 13, 2025

Hi @Sebastian Santoyo,

I may be mistaken, but if I understand your use case correctly, I have the impression that you are making things overly complex.

Assuming that you just want to copy values from a newly created work item from a linked work item from type requirement, you can use a smart value to refer to that specific requirement item to copy values from.

In your rule, you are trying to use a {{lookupIssues}} smart value, but:

  • if you want to do this, you would need to run a Lookup Issues action first in order to get data into that smart value (which you are not doing in your rule, so there's nothing to lookup from);
  • if you only have 1 item to copy the data from, there is no need to do a lookup via JQL

I have a sample rule in a test environment of mine that looks like this:

Screenshot 2025-07-13 at 13.12.02.png

It uses the link to another item to determine where to get its source data from and the built in function Copy (field value) from destination work item to locate the linked work item as a source for the data.

It could be that you could simplify your copy logic very much in the same way to achieve your goal.

Hope this helps!

Sebastian Santoyo
Contributor
July 14, 2025

Hello Walter thank you so mucho for your help!

 

Please go to the bottom of the page, I found a solution with part of the structure that @Trudy Claspill gave me. take a look at the end of the thread with Trudy.

Possibly it could be useful to you in a future and the community

 

 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events