Jira Automation: Manually run a rule that creates an epic, and then 4 tasks assigned to that epic

[Brian Ward]

Hey folks, I'm getting close to finding answers but nothing that works EXACTLY. 

I'm trying to create a rule that I have to manually trigger. Once I hit the button I want to create an epic, then within the same rule I want to create 4 new tasks and have them all assigned to that new epic I just created. 

I'm finding settings to grab the Epic Link from the "trigger issue", or to have rules automatically trigger when certain Epics are created, but none that work with a manual execution rule. 

Can anyone tell me if this is possible? 

(In theory once this works I would then go in and edit the name of the Epic to match whenever the corporate name of our current Sprint is and have all the associated tasks on that Epic. I could possibly automate this as well, but it would require creating some kind of data structure holding all of our Sprint names and getting the rule to read the current date to find out which name to pick and... just manually doing it seems easier for now! ) 

[Trudy Claspill · Accepted solution]

Hello @Brian Ward 

Welcome to the community.

You can get the issue key of an issue you created in the rule using the smart value {{createdIssue.key}}. 

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--createdIssue--

You could then use that when creating the child issues to link the children to the Epic. I would recommend that you assign that smart value to a variable so that you have a fixed value for the Epic issue key.

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Create-variable

I think the createdIssue.key value would get updated with each child issue created (with the child issue's key) which would disrupt your actions to link the child to the Epic.

[Brian Ward]

Ah, so if I didn't assign the first createdissue.key to a variable (and lock it in, essentially), that value would change every time a new issue is created?

I'm still going through smartvalue documentation, but in theory couldn't I specify within each subsequent task to take the createdissue.key from the FIRST issue in the list that's generated? 

Edit: Nevermind I misread this part. "When working with smart values that have multiple items, you can use # with the smart value to apply your rule to every item in the list. For example, the smart value {{issue.comments}} is used to access and return an issue's comment. However, if the issue has multiple comments, the smart value {{#issue.comments}} would make your rule iterate on each comment individually. When using #, you must close the expression with {{/}}." So this isn't used to navigate to a specific item in a list, it's used to make sure whatever rule I'm creating gets applied to everything in the list? (not quite relevant to this particular use case but I wanted to make sure I understood this correctly) 

[Trudy Claspill]

Looking at the documentation, I understand it to mean that {{createdIssue}} (notice that is singular) access the last issue created in the rule before the point at which you are trying to use the smart value.

There is a {{createdIssues}} (notice that is plural) that can be used to reference the list multiple issues created through a single automation rule.

I have not experimented with these smart values tho see how they change as multiple actions are executed to create issues in a rule.

[Brian Ward]

Thanks for the quick reply! So to accomplish my goal I'd basically : (pseudo code) 

Manually hit a button that - Creates an epic

then

create a variable (NewEpic) that is NewEpic = createdIssue.key (I'm not sure what specific syntax I'd use to grab the value of the new epic and lock it into the NewEpic variable)

then 

creates a task, which has an Epic Link = NewEpic

Does that sound correct? Now I just need to find the right syntax for all of it

Edit Update: So, using the {{Createdissue.epic.key}} smart value is grabbing the Epic from the issue I run the rule from, not grabbing the epic from the Epic the rule creates. What am I missing?

[Trudy Claspill]

Hello @Brian Ward 

Whenever you want help debugging a rule you have created we need to see the details of your rule. We can guess at what might be wrong, but our guesses may be completely wrong without being able to review the actual rule details.

My first question, without those details, is why are you using {{Createdissue.epic.key}}?

[Brian Ward]

Hi Trudy, 

Truly, I don't have a great answer for you. I think I tried your first suggestion, {{createdIssue.key}} and it didn't work, so I looked for alternatives in the documentation that might do the same thing, and specifically grab the EPIC. I had gotten it into my head that createdIssue.key was such a broad statement that surely it just must not be grabbing the specific info I want. I think at that point it was late and I was losing track of what I was trying for. 

But I went back and tried it again using exactly what you said, and it did indeed grab the Epic from my created issue. I saved it into a variable, and when I put that variable into the created tasks, it worked like a charm. 

To be honest I'm still not sure how the smart value createdIssue.key works, and how it knew to grab the epic value, and not anything else from the Epic I created, but, it solved my problem. So, thank you!

[Trudy Claspill]

Hello @Brian Ward 

{{createdIssue}} is, essentially, the entire newly created issue. You reference different fields in that issue using .<fieldname>. Examples:

Get the key for the last issue created within the rule: {{createdIssue.key}}

Get the Status for same: {{createdIssue.status}}

Get the Due Date for same {{createdIssue.duedate}}

{{createdIssue}} is like {{issue}} and {{triggerIssue}. Each one references an issue within the rule.
- {{issue}} points to the current issue being operated against. If you are in a branch it points to the current issue within the branch. If you have not branch in your rule, then it points to the issue that triggered the rule.
- When you do have branching and you want to reference data from the trigger issue while you are in the branch then you would use {{triggerIssue}}

You can learn more about smart values in this overview:

https://support.atlassian.com/cloud-automation/docs/what-are-smart-values/

This page talks more about the smart values that represent individual issues. This one specifically talks about {{issue}} but the child elements it mentions apply to any smart value that represents an issue:

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/

Smart values can be a daunting topic when you are first starting to use automation. Don't hesitate to reach out to the community when you have questions.

If your original post/question/problem has been addressed by my responses, it would be lovely if you would mark this Answer as Accepted to help other community members find posts with working solutions.

[Stefan Salzl]

Hi @Brian Ward 

If I got your requirement right you´d like to my manually triggered rule an epic is created with 4 tasks as child (tasks have epic link to newly created epic).

I tested the following rule in my system and as far as I understood the requirement correctly it does the work:

detailled specification of my rule:

• Trigger: manual 
• then: Epic is created
• branch: recently created issue
  • this branch takes the created Epic into scope of {{issue}} 
  • this means you can use the epic throughout this rule with the issue smartvalue
• within the branch create a task
  • within the create action the epic is set directly in the field "epic link"
  • by using the "copy from issue" option it´s referring to the issue from the branch which is the epic
• you could then specify some more tasks with the same setting

Hope this is helpful.

Best
Stefan

[Brian Ward]

Hi Stefan, there's some stuff in here I hadn't considered, I'm going to try it out and report back. My main issue was solved below, but I could always use alternatives and better understanding. 

[Trudy Claspill]

@Stefan Salzl 

Nice! That is a branching option I have not used before. I'm always learning great things from the posts in these communities!

[Stefan Salzl]

@Trudy Claspill 

That‘s one fact I love most about the community:
The longer I am part of it the more I learn.

I feel honored I could share something new and helpful.

Thanks for your feedback.

Best
Stefan

[Cloudites Owner]

Yes it is possible.