Automation copying values from Cascading Custom Field to a linked issue in a different project

[claire_povey]

Hello, 

I am looking for assistance with Jira Automation please. 

I have 1 JSM project and a Jira Project, both have the same Cascading Field. Users select the Cascading Field values during ticket creation on the portal, when issue is submitted automation then creates an Epic in a Jira project. I am trying to automate the copying of the values of the cascading field from the JSM ticket to the linked Jira issue. 

I feel like I've tried every possible permutation of the automation configs but nothing seems to be working. I have an automation which copies the values from the epic to it's children and that works fine, but this one has me stumped (or I've simply been looking at it for too long and have Jira Automation Blindness), so any help would be gratefully received. 
Cascading field is called Contract, it's ID is 10740
The JSM project (BDUK) is where the values are held
The Jira Project (PAP) is where I would like the values copying to. 

The automations scope is set to Multiple Spaces with BDUK and PAP being selected. 
Trigger is set to Work Item Created on Project BDUK
Branch then set for all linked work items
Then Edit work item fields using additional fields set to:
{
"update": {
"customfield_10740": [
{
"set": {
"value": "{{triggerIssue.fields.customfield_10740.value}}",
"child": {
"value": "{{triggerIssue.fields.customfield_10740.child.value}}"
}
}
}
]
}
}

I have also tried to add the automation to the PAP project and used the below to look at getting the info from the linked issue, but this didn't work either:

 {
"fields": {
"Contract": {
"value": "{{issue.issuelinks.inwardIssue.fields.Contract.parent.value}}",
"child": {
"value": "{{issue.issuelinks.inwardIssue.fields.Contract.child.value}}"
}
}
}
}

If anyone is able to assist I would be forever grateful :-)

[Christos Markoulatos · Accepted solution]

Hi @claire_povey 

Use the below

{
"fields": {
"customfield_10538": {
"value": "{{triggerIssue.customfield_10538.value}}",
"child": {
"value": "{{triggerIssue.customfield_10538.child.value}}"
}
}
}
}

works fine and creates the epic in the other project and copies the cascade field values. use your own custom field.

Hope this helps!

[claire_povey]

Hi Christos, 

Thanks for the reply, your answer seems to be what I already had, but I did actually resolve the issue by adding a delay of a few seconds. 

I really appreciate your response and you taking the time to assist 

[Bill Sheboy · Accepted solution]

Hi @claire_povey 

Without seeing your entire rule and audit log details, you describe solving this symptom by adding the Delay() action, but you may have only partially / temporarily solved the problem.

The root causes are known, racetrack timing defects:

• With triggers such as Work Item Created, the rule can start running before all of the data is available to the rule...Indeed, the work item may be in an unstable state, perhaps without even a type yet!  Thus, later rule actions, conditions, etc. get incomplete data.  The mitigation for this defect is:
  • Immediately after the Work Item Created trigger, always add a Re-fetch Work Item Data action.  This will slow the rule slightly, reloading the data before the steps proceed.  A Delay() action does not reload the data, and so may not help.
  • Never add conditions directly to the Work Item Created Trigger.  Instead, add the conditions after the above noted re-fetch action.
• Some smart value expression parsing is slow, and this can prevent JSON expressions  from completing before they are validated / used in the action.  This often happens with the Send Web Request action, but can also happen with advanced edits in Create or Edit Work Item actions, asset data, and just-in-time smart value lookups (e.g., subtasks).  The mitigation for this defect is:
  • Using the Create Variable action, build and store your JSON in a variable.  This will force it to fully evaluate before use.  And, this can help with debugging the rule by logging the variable.
  • Use the variable as the data for your advanced edit

At a minimum, I recommend adding the re-fetch and moving the conditions from the trigger.

Kind regards,
Bill

[claire_povey]

This makes sense, thank you Bill. I will add the re-fetch now. 

I will investigate how to build the variable and give that a shot too. 

I really appreciate your response :-)