Variable is not fetching the right values.

[PANKAJ MISHRA]

Dear members.

I am trying to create an automation for generating email alerts for the features with all child issues as Abandoned/Done/Accepted.

I have created a Variable - variableOutSideBranch at top of the rule with smart value as INIT. I am then creating a Branch to iterate over each features for child checks and appending such into another same variable as variableOutSideBranch witn smart value as  {{variableOutSideBranch}}{{featureRows}}. I could see Features are appending inside the branch. 

However when I call the same variable outside the branch to perform actions, it does not the the same value as what it had inside the branch and reset to one at top of the rule. This breaks the automation as this does not have features detail I obtained inside the branch and appended to same variable.

Please note I am not using any third party addins/Apps and sticking to pure Jira Cloud native automation resources.

Can someone guide me rectifying this issue?

[Bill Sheboy]

Hi @PANKAJ MISHRA 

For a question like this, context is important for the community to help.  Please post the following:

• what version of Jira are you using: Cloud, Server, or Data Center
• for Cloud, what type of project is this: company-managed, team-managed, JPD, etc.
• an image of your complete automation rule in a single image for continuity
• images of any relevant actions / conditions / branches
• an image of the audit log details showing the rule execution
• explain what is not working as expected and why you believe that to be the case

Until we see those...

Branches in automation rules run in parallel and asynchronously, with no guarantee of when the branch will finish up until the last step of the rule.  (The exception is branches over one-and-only-one thing, such as branch to parent.)

What this means for the rule you describe is the created variable repeatedly gets created and thrown away with each pass through the branching loop.  And so, no accumulation is possible.

A workaround for your scenario is using the Lookup Work Items action, inverting the JQL condition to find the children, and then extracting the parent work items meeting your criteria.  Finally, use a second lookup with JQL to gather any details needed about the "features" for the email.

Kind regards,
Bill

[Bill Sheboy]

@PANKAJ MISHRA , it helps to post an image of the audit log, rather than excerpts of the text.  That provides better context to compare to the rule image.

The rule you show branches over the Feature type work items using JQL, and thus it will send an email for each one.  There is no way with the current features of automation rules to:

• iterate over the Features
• to gather each one's child Stories
• and send all of that in one single email using branching 

There is no "group by" list feature for automation rules.

Such scenarios are normally handled with external reporting apps from the marketplace. 

There is a more complicated workaround using text replacement, but it only works when the total number of work items is fewer than 100 items.  The basic idea is to repeatedly use Lookup Work Items, first getting the Features and then their children to build the email.

• use the Lookup Work Items action to find all the relevant Features
• use a Smart Values Condition to confirm some were found...
• extract just the keys for the Features to build a dynamic JQL expression
• use that dynamic JQL with Lookup Work Items again to return all the children for the Features, ordered by the Parent key

parent IN ( {{lookupIssues.key.join(", ")}} )
 AND issueType=Story
 AND status NOT IN (Abandoned, Accepted, Done)
 ORDER BY Parent ASC, Key ASC

• use a Smart Values Condition to confirm some were found...
• using long-format iterator, extract the needed data, to create the email, adding any formatting (e.g., HTML for columns / rows) as needed

{{#lookupIssues}}
  {{parent.key}}: {{parent.summary}}; {{key}}: {{summary}}
{{/}}

[PANKAJ MISHRA]

@Bill Sheboy Appreciated your response. Let me try this way once.

[PANKAJ MISHRA]

Thanks for your inputs   @Bill Sheboy @Arkadiusz Wroblewski  

Tried your suggestions, however did not get the intended outcome. Sorry new to this and hence may be stuck. Below are the artifacts, if helps

1. Rule Trigger at scheduled time
2. Starting branch to loop through each feature
3. Checking the count of active stories against each feature
4. Checking if the active stories count is 0>6

 

5. Logging in the output of Step 4.
6. Sending an email using
   {{#lookupIssues}}
     {{key}}: {{Summary}}
   {{/}}

      

Issues faced:
1. Its triggering one mail per feature still.

2. It duplicates the value of same feature a number of times which is equal to number of active stories beneath that feature (eg duplicates the feature 4 times, if there are 4 active stories under it.
   
   

 ____________________________________________________________________________

Audit log as below
Scheduled

03/24/2026, 15:13:26

BRANCH

Branch rule / related work items

03/24/2026, 15:13:26

View associated items

Lookup work items

03/24/2026, 15:13:29

A search during custom value definition found no work items.

View associated items

{{smart values}} condition

03/24/2026, 15:13:29

Condition not passed for:

0

greater than

0

The following work items did not match the condition:

Blank-19958, Blank-20054, Blank-20113, Blank-19919, Blank-19780, Blank-18419

Condition passed for:

1, 2, 3, 6, 4, 7, 5, 8, 10, 14, 18, 15, 32, 74

greater than

0

The following work items passed:

Blank-20432, Blank-20134, Blank-19959, Blank-19924, Blank-19926, Blank-19955, Blank-19952, Blank-19957, Blank-19951, Blank-19954, Blank-19956, Blank-20055, Blank-20763, Blank-19931, Blank-19921, Blank-20582, Blank-19920, Blank-19927, Blank-19933, Blank-19929, Blank-20056, Blank-19953, Blank-20057, Blank-19930, Blank-20410, Blank-19928, Blank-14583, Blank-14598, Blank-19819, Blank-19784, Blank-19821, Blank-19765, Blank-118

{{smart values}} condition

03/24/2026, 15:13:29

Condition passed for:

1, 2, 3, 4, 5

less than

6

The following work items passed:

Blank-20432, Blank-20134, Blank-19959, Blank-19924, Blank-19926, Blank-19955, Blank-19957, Blank-19956, Blank-19951, Blank-19952, Blank-19954, Blank-20763, Blank-20055, Blank-19931, Blank-19921, Blank-19927, Blank-19929, Blank-19920, Blank-14598, Blank-19784

Condition not passed for:

6, 7, 8, 10, 14, 18, 15, 32, 74

less than

6

The following work items did not match the condition:

Blank-20582, Blank-19933, Blank-19953, Blank-20056, Blank-20057, Blank-19930, Blank-20410, Blank-19928, Blank-14583, Blank-19819, Blank-19821, Blank-19765, Blank-118

Log action

03/24/2026, 15:13:29

Log

Summary : Blank-20432-->Active Child 1, Summary : Blank-19959-->Active Child 1, Summary : Blank-20134-->Active Child 1, Summary : Blank-19924-->Active Child 1, Summary : Blank-19926-->Active Child 1, Summary : Blank-19954-->Active Child 1, Summary : Blank-20055-->Active Child 1, Summary : Blank-19955-->Active Child 2, Summary : Blank-19957-->Active Child 2, Summary : Blank-19951-->Active Child 3, Summary : Blank-19956-->Active Child 3, Summary : Blank-20763-->Active Child 3, Summary : Blank-19952-->Active Child 3, Summary : Blank-19931-->Active Child 3, Summary : Blank-19921-->Active Child 3, Summary : Blank-19927-->Active Child 3, Summary : Blank-19920-->Active Child 4, Summary : Blank-19929-->Active Child 5, Summary : Blank-14598-->Active Child 1, Summary : Blank-19784-->Active Child 5

Send email

03/24/2026, 15:13:30

Successfully sent email for work items (with message ids):

Blank-20432 (88085ca4-df50-4a1c-8f84-5673bed43d99), Blank-19926 (5642e4c4-3611-414c-bcd6-d6428af7dd31), Blank-20134 (748a8898-9f16-4400-96e9-d5f674305d94), Blank-19924 (026e94e3-27f3-4399-bedb-c9b13cffea43), Blank-19959 (e6ff802e-acf0-4d73-99c1-2834d165bd06), Blank-19954 (4b7e6f34-a836-476e-bdcb-ce416d9cf81e), Blank-20055 (a5085cd2-19b1-449c-8402-aa70cc8dd0f9), Blank-19955 (9a856032-4f23-4ce2-96f3-9cadb876f451), Blank-19957 (5609f302-e94f-49fc-9363-2d43a5721ff1), Blank-19956 (aa4a2037-15d4-4216-aa7b-be1a02b8ac83), Blank-19951 (8b7f822d-86ec-438f-8761-5761e0b160ee), Blank-20763 (d8e4470a-0898-4d92-9d2b-38a5c2b414cf), Blank-19952 (599c4f85-66c8-43cf-b530-278d9962a9f4), Blank-19927 (d595cf51-cbc1-449f-be00-af25f038e314), Blank-19921 (6f81c1f6-95bd-4818-ba7b-dc60784545b6), Blank-19931 (ceb2858e-f4fd-4455-9cf4-76768c04d9ad), Blank-19920 (46e59fea-e775-4e2b-8fab-ca1cd23c9e36), Blank-14598 (3f932ba5-7350-408e-b85b-5aa9f02b36f7), Blank-19929 (017dc691-19ad-4ed1-a9e6-d1bea438be3f), Blank-19784 (be68d59c-2c88-4867-8f95-1c67b180d039)

[Arkadiusz Wroblewski]

@PANKAJ MISHRA 

From the audit log, this looks like the rule is doing exactly what it was told to do.

Because Send email is still inside the branch, it will send one email for each item processed there.

And because lookupIssues is returning the matching child issues, the same Feature will appear multiple times when it has multiple active Stories underneath it.

So I would not focus on the variable here. The bigger issue is the rule design.

You will likely need to build the unique Feature list first, and only then send one email outside the branch.

[PANKAJ MISHRA]

Thanks @Arkadiusz Wroblewski 

When you say - "You will likely need to build the unique Feature list first, and only then send one email outside the branch", could you please elaborate more. If this list is to be built inside the branch and then referenced outside the branch while sending email

If you meant - like tagging such features with lets say with specific keyword/s and filtering these based on that with a lookup outside the branch to send as a table/list

Let me if otherwise

[Arkadiusz Wroblewski]

@PANKAJ MISHRA 

@Bill Sheboy has identified the main limitation here and my answer was little oversimplified.

So well......

Because your rule branches over Features, anything inside that branch runs once per Feature, so the email action will also run once per Feature. With native Automation, there is currently no simple group by parent option that would let you branch through Features, gather their Stories, and then send all of that in one combined email.

That is why your current approach keeps producing multiple emails and repeated results.

The workaround is to avoid building this through the branch itself, and instead use Lookup Work Items in stages: first get the matching Features, then use those Feature keys in a second lookup to get the related Stories, ordered by parent, and finally format that result into one email body.

His workaround will be probably last resort how to handle that out of Box with Automation.

Automation are powerful but they have their limitation and with your use case, we say in Germany... "Grenzwertig"

[Arkadiusz Wroblewski]

Hello @PANKAJ MISHRA 

What you’re seeing is expected in Jira Cloud Automation.

When you go into a branch (“for each issue…”), Automation is basically running in a separate context. So even if you “append” to a rule variable inside the branch and you can see it growing there, that change doesn’t reliably carry back out to the main rule once the branch finishes. Outside the branch the variable will still look like whatever you initialized it with (your INIT).

So the fix isn’t “tweak the smart value”  it’s using a different pattern.

What works well in native Automation:

Don’t build a big string variable across a branch.

Instead, collect the issues you care about (e.g., with Lookup issues) and then build the email content at the end using a loop like:

{{#lookupIssues}}

- {{key}}: {{summary}}

{{/}}

If you truly need an “accumulator”, use something that persists, like an issue entity property (store the running text there during the branch, then read it once at the end). That’s the closest “append” behavior you can get without an app.

If you post a screenshot or list of your rule steps (especially how you’re checking “all child issues are Abandoned/Done/Accepted”), it’s easy to suggest the cleanest native rule structure for a single consolidated email.

Hope it helps 👍