Automation to Update Trigger Issue's Field Using Data from linked issue

[lakshyajeet_swami]

I am attempting to update a custom field available on the FMEA work type using data sourced from a linked SRA work type within the same Jira project. The goal is to have a single automation rule that functions correctly regardless of which issue type the link is created from.

Current Automation Configuration

The automation is triggered when a work item is linked, and it is structured with two separate branches to handle both possible link directions.

Branch 1: Trigger Issue is FMEA

• The automation first checks whether the triggering issue type is FMEA
• A branch for linked work items is created
• Within that branch, a condition verifies that the linked issue type is SRA
  (At this point, the SRA becomes the current issue context)

Intended behavior:
Use a field value from the SRA issue to update a custom field on the destination issue (FMEA).

Issue encountered:
I am unable to update the FMEA issue from this branch. The automation does not update the custom field on the triggering FMEA work item, even though the correct SRA issue is identified and its data is available.

Branch 2: Trigger Issue is SRA

• The automation checks whether the triggering issue type is SRA
• A linked work items branch is created
• The linked issue is validated to be of type FMEA
• The custom field is updated on the current issue, which at this point is the FMEA

✅ This branch works as expected, since the automation directly updates the current issue (FMEA) using data from the trigger issue (SRA).

Core Challenge

The challenge arises in Branch 1, where:

• The automation context switches to the linked SRA issue
• However, the value needs to be written back to the original triggering issue (FMEA)

Because the current issue context inside the branch is SRA, the automation does not correctly update the destination (trigger) FMEA issue unless explicitly handled.

[lakshyajeet_swami · Accepted solution]

What I did was created a lookup issue and then created a variable out of it to fetch the data from lookup issues then finally updated the field at destination, Please see below ss for reference.

[Bill Sheboy]

Hi @lakshyajeet_swami 

As an FYI, most work item links have a "direction" which is always followed for the Work Item Linked trigger.  That is, regardless of from which work item the link is added (i.e., in opposite directions) the same, forward-direction-end will be the work item which triggers the rule.  This makes handling more predictable in rules for branching, etc. to use the {{triggerIssue}} versus {{destinationIssue}}.

To learn more, please see this great explanation from @Trudy Claspill in an earlier question:

https://community.atlassian.com/forums/Jira-questions/How-can-I-get-field-from-linked-issue/qaq-p/2807497#M1050229

Kind regards,
Bill

[Arkadiusz Wroblewski]

Hello @lakshyajeet_swami 

Your analysis is correct.

Once you enter a Linked work items branch, the context switches to that linked item. So in Branch 1, {{issue}} is the SRA, while the original FMEA is only available as {{triggerIssue}}. That is why the edit step inside that branch is not updating the original FMEA the way you expect.

Try not to “go back” from inside that branch. I would rework Branch 1 so the branch is only used to identify/check the linked SRA, and the actual update of the FMEA happens in the trigger/main context. Otherwise the rule stays on the linked issue context and you end up editing the wrong side.

Also, one small but important detail, for the Work item linked trigger, Jira runs the main rule on the source issue, and the other side is the destination issue based on the link direction, not based on which issue screen the user linked from. So I would build the logic around source/destination, not around “linked from FMEA” vs “linked from SRA”.

How does Jira automation "Issue linked" trigger pick the Source and Destination issue? | Automation | Atlassian Support

[lakshyajeet_swami]

Hi @Arkadiusz Wroblewski , 

Thanks a lot for the prompt support But I believe I was able to resolve this issue own my own. 

What I did was created a lookup issue and then created a variable out of it to fetch the data from lookup issues then finally updated the field at destination, Please see below ss for reference. 

[Arkadiusz Wroblewski]

@lakshyajeet_swami 

Well Create Variable, Save it and then Use are also legit Solution in this Use Cases.

[lakshyajeet_swami]

As shown in the screenshot below, Branch 1 is where changes are required for the automation to function correctly.

In this branch, the automation workflow is structured as follows:

• The rule is triggered when a work item is linked
• A condition confirms that the triggering work item is of type FMEA
• A Linked Work Items branch is then created
• Within this branch, a condition validates that the linked work item is of type SRA, which at this point becomes the current issue context

At this stage, the automation correctly identifies the linked SRA work item and has access to the required data field (e.g., Risk ID). However, the update action currently fails because the automation is operating within the SRA issue context, while the field that needs to be updated exists on the original triggering FMEA work item.

The expected behavior in Branch 1 is for the automation to:

• Traverse back from the linked SRA issue
• Reference the triggering issue (FMEA)
• Update the custom field on the FMEA work item using values retrieved from the SRA

At present, this reverse update does not occur, as the automation attempts to update only the “current issue” (SRA) inside the linked-work-item branch.