Atlassian Team members are employees working across the company in a wide variety of roles.
December 8, 2021 edited
Hi all,
This thread has some great discussion around the feature, thanks @Bill Sheboy for the guidance you've provided around its usage. A note on the issue you pointed out around variables not working as parameters to functions, we recently release a fix for this, so you should now be able to use the variables as you previously were intending to.
Just to weigh in on some aspects and the purpose of the feature, and our plans for improving it in the future: The underlying functionality of the Create Variable component was built to accomodate a few new features back in 2020, such as the Lookup Issues component, which under the hood is piggy backing the smart value variable system. When we built this functionality, we saw some value for our customers in the ability to 'alias' long and complicated smart values, which might need to be used multiple times within a rule. With the create variable action, users can edit/maintain repetitive smart values in a rule in a single component, instead of having to update it in multiple spots within a rule.
As you've noted, the biggest limitation of the feature is that it does not store and respect the underlying object types. When you create a variable, it evaluates the text result of the smart value, and stores that string. Subsequent usage of the variable will always just be accessing that string result. However, another recent addition we built was the 'Advanced Branching' component. When we built this, we created a way for the system to hook into and store the underlying objects of a smart value template. This is why the components in an advanced branch can treat the branched variables as their raw type (issue, comments etc). Now that we have a way to do this, we are looking at introducing the same ability to the Create Variable component. We have no ETA on this update, as we have to be cautious as to not detrimentally affect how existing rules are using the feature, but it is something we are aware and looking into. Once it is done, it will make smart value variables much more flexible and useful.
PS. The other issue discussed here around asynchronous branch executions, and the ability to 'pause' then continue rules after branches are complete, is something we are also keenly aware of. Adding this ability would also work towards enabling branch components to affect variables/state of the rule's root execution. We haven't committed to a deadline for solving this problem, but it is definitely high up there on features we want to introduce to the platform.
Hope this provides some useful perspective on the Create Variables component!
However, another recent addition we built was the 'Advanced Branching' component. When we built this, we created a way for the system to hook into and store the underlying objects of a smart value template. This is why the components in an advanced branch can treat the branched variables as their raw type (issue, comments etc). Now that we have a way to do this, we are looking at introducing the same ability to the Create Variable component.
One thing to be sure to clarify here is "points of evaluation" for the content of a variable.
(Sorry, but one of my frustrating superpowers is realizing ambiguity where most people don't see it).
The original behavior of Create Variable was nice and simple - the string that was stored was the result of a single evaluation at that time. The variable didn't change thereafter (unless Create Variable was used on that same variable).
A phrase like "components ... can treat the ... variables as their raw type" makes me wonder about re-evaluation of the value of the variable. If some aspect of a "raw type" can change (e.g. a field in an issue, a value modified earlier in the rule, etc), then does the variable reflect that change or not?
For example, consider two variables A and B, created in that order. B includes a reference to A. If I later change the value of B, will the value of A reflect that change or not?
This is just a request for a lot of clarity about how these features will actually work. I've struggled for years to come up with a workable "user model" in my head about how various aspects of Jira Automation work, only to be surprised at times when my user model is inaccurate.
I may be at a disadvantage compared to many automation users, due to my decades as a software developer across many programming languages. I've come to expect clear, deterministic, well-documented behavior from procedurally-oriented approaches. Jira Automation is a different duck (with good reason), yet we'll all be more successful with clarity of behavior and implementation.
That said, I'm definitely looking forward to future improvements!
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Thanks for your insights and updates! Is there a work item/suggestion issue for the typing change to created variables which the community may watch for updates, or is this article the place to watch?
And thanks to @Mykenna Cepek for driving toward clarity! (I'm guessing we won't find a Backus–Naur form spec for automation rules in the documentation :^)
You've hit the nail on the head, what you're describing is exactly one of issues we are tackling with the feature changes involved for the component. The Create Variable feature does in fact have the concept of 'point-of-evaluation', where it in fact can lazily evaluate smart value only when it is actually used in the rule, essentially giving it a lot of flexibility. However, we don't expose or use that feature right now, as communicating these concepts clearly in the UX is the bigger challenge.
For now, as you've pointed out, the Create Variable component evaluates once, and stays that same static value throughout the rule (until overwritten). This behaviour will not change, regardless of any changes we may introduce to the type/class of the smart value (so in the case of A referencing B, updates to B will not affect A). If we do allow any variation on this functionality, it would be made as an option the users can select, and not as a default behavioural change.
@Bill Sheboy We didn't have a public tracker for this, as it wasn't a commonly asked for/thought of issue, but I have just added a public tracker here for it.
Thanks for that reply, @Sam Harding. Looking forward to these changes.
I was going to add a link to this discussion from the public tracker you created for this (AUT-2332), but comments are not enabled (as they are on JAC).
It might help add context to AUT-2332 if it linked to this discussion.
Atlassian Team members are employees working across the company in a wide variety of roles.
December 13, 2021 edited
No worries @Mykenna Cepek, I've added a link back to this post/thread in that ticket. If you guys have any further thoughts on the matter, we'd love to hear it too!
This worked for me, Thank you so much for the solution @Cristiano
I was struggling to make the variable global which is created inside a branch, by declaring the variable as null before the logic, I can use it in other branches.
35 comments