In Jira Automation, Smart Values of issues created in a branch are not available to main trunk

[Mee Soo]

Heyyyy there,

It seems that if I create an issue inside a branch (specifically in my case in an IF/ELSE block), I cannot use {{createdIssue}} or {{createdIssues}} to reference it once I am back outside of that branch.

The main trunk does not have access to the smart values of issues created in the branch.

Similarly, when creating a lookup table in a branch, it is not accessible to the main trunk, so I can't send data back that way. 

Am I missing something? It seems to me that if the docs say that {{createdIssues}} is "A list of issues that have been created in the rule." then it should be just that. Currently, it seems that it is "A list of issues that have been created in the rule EXCEPT for all the issues that may have been created in branches".

I get why it's happening, but it seems like many people would need this to work, so I'm guessing I am overlooking something, or there's a workaround I am not thinking of.

My automation is to create several issues inside an Epic, triggered when the Epic is created. Those issues are sometimes created in IF/ELSE blocks. Each issue created must be blocked by the previous one which is easy to configure using {{createdIssue.key}}. But if the previous issue was created in a branch, I cannot link to it (as blocking) because {{createdIssue.key}} is NOT the latest issue created in the rule, it's instead the latest issue created in the main trunk.

Thanks for any guidance, I'm kinda new at this.

[Bill Sheboy · Accepted solution]

Hi @Mee Soo -- Welcome to the Atlassian Community!

That is a known symptom/behavior and is based on how branches work...Scope is important with branches when trying to understand smart values:

Branches on one-and-only-one thing (e.g., branch to parent) get run inline, as if the branch was not there.  For that case I believe an issue created inside that branch would impact {{createdIssue}}

Branches that could be on more than one thing (e.g., JQL, advanced branches, etc.) are run asynchronously and in parallel.  In fact, there is no guarantee of when such branches will complete...up to the last step of the rule.  Although you can create issues and {{createdIssue}} would be update inside of such a branch, outside of the branch the smart value update is gone when the separate processing thread ends.

If you describe the problem you are trying to solve/scenario, perhaps the community can suggest an alternative approach to help.

Kind regards,
Bill

[John Funk]

Hi @Mee Soo  - Welcome to the Atlassian Community!

Can you share your rule, and then what you are trying to do? 

[Mee Soo]

Oh shoot: https://jira.atlassian.com/browse/AUTO-154 and https://jira.atlassian.com/browse/AUTO-110

Looks like this is the problem I am running into. :(

[Mee Soo]

Hi, thanks for the feedback so far.

Here's a simplified version of what I am trying to do.

• Create several issues in sequence, where each issue created is blocked by the previous one.
• Some of the issues are conditional, based on "some value", like a user input when the rule is triggered (or alternatively maybe some field in the triggering issue).
• Because a conditional issue is created in a branch (IF/Else block), the subsequent issue cannot be blocked by it using "Most recent created issue".

I am using an IF/Else because I need the rule to continue processing even after a false. If I used an "Issue field condition" to create the issue in the main thread, it would just stop on a false and not create all the non conditional issues that come afterwards.

I am trying to avoid duplicating the creation of the SAME issue in several branches. There are a lot of issues being created in my rule (about 20).

I just thought of a way, but it's not great: Instead of conditionally CREATING the issues, I could ALWAYS create them, and then conditionally DELETE the Most recent issue created if it shouldn't have been created.  <_ edit: won't work because the deleted issue will be the "Most recently created issue" and that will mess up my links downstream.

I'm sure there is a better way...

[Mee Soo]

Since all the issues are created in an Epic, I would have access to that list of issues at the end of the rule. When I create the issues in a branch, I could flag them, then at the end of the rule, loop over all the issues in the Epic, and for the ones that are flagged, link to the previous issue in the epic. But I don't know how to reference the index of the previous issue in that loop.

[Mee Soo]

I wish there was a way to create a condition that did not branch out and did not terminate on a false. Is there? There should be...

[Bill Sheboy]

Thanks for clarifying and posting your rules, @Mee Soo 

What I noted earlier is for branches.  For the if/else when I tested the {{createdIssue}} is indeed set correctly.

The challenge for your rule is the first issue create is inside of the if/else...and when the issue is NOT created there is not "most recently created issue".  What were you expecting to happen for that case?

Next...how many conditions do you plan for your rule?  A rule can only have 65 components/steps and if you have many conditions I expect you will run into the limit.

[Mee Soo]

Hmmm... I am not seeing that {{createdIssue.key}} of the issue created within the if/else block (or "Most recently created issue") is available to the issue created outside the block subsequently. The second issue never has the "blocked by" link to the issue created in the if/esle block. If/else appears to be behaving like a branch. 

In the case where the first issue is not created, I expect the link will simply not be created, or it will be created with an issue that was created above it. 

I won't reach the 65 component limit, thankfully, but good to know that limit exists. My rule has 42 components right now, and I am done, other than this annoying linking issue.

I am curious to hear how you are getting the {{createdIssue}} to be accessible outside the if/else block! That's specifically what I need, but I cannot get it to work.

I modified the rule to test this out. The result of this automation is 3 issues created as expected, but Issue 3 is blocked by Issue 1, not issue 2.

Thanks for the help  @Bill Sheboy 

[Bill Sheboy]

I reproduced that symptom, and you have found a defect:

For a Create Issue action inside of an if/else clause, when using issue linking both the Most Recently Created Issue (drop-down value) and {{createdIssue}} smart value incorrectly identify the last created issue as any issue created *before* the if/else clause.

Now here is a work-around that may help solve this using created variables.  You should only need this for the if/else cases.

• trigger: manual, with user input
• action: create issue
• action: create variable, saving {{createdIssue.key}} as varLastCreatedKey
• if/else condition
  • condition: for your input test
  • action: create issue, linking to {{varLastCreatedKey}} instead of from the drop-down
  • action: create variable again, saving {{createdIssue.key}} as varLastCreatedKey
• action: create issue, linking to {{varLastCreatedKey}} instead of from the drop-down
• ...

This works because the second call to Create Variable using the same variable name replaces it, and so can be used outside of the if/else clause.

[Mee Soo]

YES!!!! Thank you @Bill Sheboy !!

That works. I saw something to that effect earlier but was skeptical and did not try it.

So setting the variable outside of the if/else first, then updating its value inside the branch results in the updated value being available outside the branch. Huh!! LOL.

[Mee Soo]

Bummer I can't accept your reply as the "answer" because it's a reply....

[Bill Sheboy]

Indeed...there is no "Edit Variable" action yet and so variable-shadowing is the work-around to help with this other work-around  :^)

[Marc Isikoff]

Similarly we need the right smartvalue for within a Branch on current issue.

Branch on current issue fires for the issue tripping the automation such as public comment is made, etc.

Within the branch, I want to make sure a custom data/time field is empty before giving it {{now}} and this is tracking an SLA data/time met under Time to First Response since there is no explicit field to capture that. But we want to capture it once, not every time a response is given so only if already empty.

So I just need the right way to ask if customfield_123456 is empty in the context of a branch on current field.

[Bill Sheboy]

Hi @Marc Isikoff 

I recommend creating a new question, showing your complete rule and audit log details, and perhaps link back to this thread.  That will get the most visibility for the community to offer suggestions.  Thanks!

Kind regards,
Bill