nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automation to set field value from parent epic

ngaidakov

I'm trying to set up an automation for a project such that new issues created under an Epic inherit their Account field value from the parent epic.

I have set up the following automation:
When: issue created
If: parent exists
Then: Edit issue fields – Copy Account from Parent issue

I have tested creating issues under an epic with an Account set. The Audit Log claims that the automation ran successfully for these issues but the Account is not set.

However, when I tried it out on a field other than Account (I tried Due date) the copying seemed to work. This suggests there's something about the Account field that breaks copying.

The Account field comes from our Tempo plugin. It can only be assigned a value from a pool of accounts set up through Tempo. I wonder if this means it's a more complex value that cannot be copied directly. Would it be achievable through the advanced JSON config?

Accepted answers

ngaidakov

I'm afraid the answer in the end was I made a silly mistake setting up my issues when testing this rule, and it actually does work as-is. Sorry!

All comments

Kalyan Sattaluri_iinm1n

Hello and welcome @ngaidakov

If you are working with issues under epic, instead of copy from Parent, can you not choose copy from Epic?

ngaidakov

I could try that but from my experimentation with copying another field I suspect the "from Parent" part of it isn't the issue. Isn't Epic as a relationship between tickets a deprecated concept, to be replaced by Parent?

Bill Sheboy

Hi @ngaidakov -- Welcome to the Atlassian Community!

For a question like this, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected. Those will provide context for the community to offer ideas. Thanks!

Until we see those...

Three possible causes for that symptom are: trigger timing, dynamic fields, parent data loading.

#1) The Issue Created trigger can fire so quickly that some of the issue data may not be available by the time the rule starts. This can cause later use of issue fields to fail unexpectedly. The fix / work-around for this is to always add the Re-fetch Issue action immediately after the Issue Created trigger. This will slow the rule a bit, reloading the issue data before the other steps continue.

#2) I am not using Tempo, but as it is a marketplace addon some of the fields may be dynamically generated from their product. This can cause problems in rules because the data may not be available fasted enough when needed. The work-around for this is to first copy the parent field's value into a created variable, and then use that created variable to set the field in the issue edit.

#3) When rules access an issue, they populate the smart values for the fields of that issue...and some data for the parent (and any subtasks). But *all of the data* for those related issues is not loaded. If rules did that, consider a single issue could drag in many issues' data! When you need other fields in the rule, they must be accessed with a branch or lookup issues. As you want to edit the trigger issue, the work-around is use the Lookup Issues action with JQL to load the parent's data, and then use smart values to set the field in the edit.

Kind regards,
Bill

ngaidakov

Thanks Bill, that's some really helpful information! It took me a while to get back to this, as I didn't know enough to attempt your more advanced suggestions.

But I'm afraid the answer in the end was, I made a silly mistake with the context I was testing for, and the rule I created actually works as-is!

I hope your answer helps someone else in future. 🙏

ngaidakov

I'm afraid the answer in the end was I made a silly mistake setting up my issues when testing this rule, and it actually does work as-is. Sorry!

Bill Sheboy

I am glad to learn you solved it :^)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

automation