Automation for Jira - Create variable (New component)

[#1]

Hi Atlassian Community!

This article is for the power users of Jira automation to show you how to use our new 'Create variable' action. 

This new action allows you to define your own smart value, which can be used in other actions and conditions in the same rule. The smart value you define can consist of other smart values, as well as math functions. (Told you it was for Power users!)

Often, in Jira automation, you want to access custom smart variables that have been defined inside a branch. If it is outside that branch then, until now it was not possible. With the new action, however, you can store a value into this variable and achieve your goal.

Let's look at an example

In some scenarios, we can build a workaround for this feature request (Add ability to branch within a branch) storing the result from the branch into a variable.

Below is an example of how this might work. 

Right now, perhaps you are thinking: "Which variable type will be set when we create a component like a variable?" I would like to point out that this variable will be a String type.

Now to the automation rule

We have created a rule to show that the Issue key SD-7 was the trigger that returned from that JQL. Then we will be able to set the variable as the result of the Branch JQL that is the issue CK-159. Through this variable, we will be able to access the value out of the branch.

Audit log result:

Before this new action, you would not be able to access the branch result so this opens many opportunities. We're very happy to announce this new feature. You can read a little more about it in our docs and we will share more updates about this component soon.

Be aware when you will use a Branch, because we cannot guarantee the order of the Branch, and in some cases, this can impact the result of the variable. We have this feature request to improve it: AUT-517 - Rule branch order is non-deterministic. In some cases it would be better for branches to execute in order.

Hope that this helps!

[Bill Sheboy]

Hello, and thanks for this information @Cristiano 

This feature will help solve problems that could have only been solved previously by adding custom fields or logging working comments as temporary storage.

Any thoughts to strongly typing these variables, such as date/time, number, list, etc.?

Best regards,

Bill

[Taranjeet Singh]

@Cristiano Thanks for sharing this useful automation feature. Is this available for for Automation for JIRA Server and Cloud versions?

[Bill Sheboy]

Hi @Taranjeet Singh 

I'm using it in Cloud right now, and it is listed on the documentation page:

https://support.atlassian.com/jira-software-cloud/docs/automation-actions/

It is not listed on the server version documentation, so maybe it is not in there yet:

https://confluence.atlassian.com/automation/actions-993924834.html

[Taranjeet Singh]

@Bill Sheboy Thanks for the information!

[Bill Sheboy]

Hi @Cristiano 

I was trying to use Create Variable, as you noted above, and I noticed a side-effect:

When the JQL in the branch spans more than one issue, the repeated calls to Create Variable do not function as you note.  Instead, each call appears to shadow the variable, and when the loop completes all of the loop-scope variables disappear.  The only thing remaining is the variable defined outside of the loop.

This severely limits the value of variables for things such as accumulators of text or numeric values.  I will submit a defect for this.

Best regards,

Bill

=======================

Update:

Per @Cristiano comments in a support ticket from my team, the processing within a rule's Branch is non-deterministic as the target issues are individually queued for execution, so order is not guaranteed within the loop (or even that the loop will complete prior to processing after the branch statement).  That would explain why Create Variable within a loop which returns more than one record "walks over" any values in a variable. 

I submitted a suggestion to add an Edit Variable action to help make the variables feature more valuable and prevent this side-effect of rule processing.

__Bill

[Cristiano]

@Bill Sheboy 

Thank you for share this update here!

I've updated this into the Article: Be aware when you will use a Branch, because we cannot guarantee the order of the Branch, and in some cases, this can impact the result of the variable. We have this feature request to improve it: AUT-517 - Rule branch order is non-deterministic. In some cases it would be better for branches to execute in order.

Also, I'd like to emphasize that this is a new component and we're looking to improve it. :) 

[Cristiano]

Hi @Taranjeet Singh _Cprime_ 

As @Bill Sheboy mentioned at Server Version we don't have this component yet.

When you receive any update probably they will update here: https://confluence.atlassian.com/automation/actions-993924834.html

Cheers, 
Chris

[Esther Strom]

Interesting. @Cristiano  - how can I use this to set a variable containing the issue key of an issue created by automation? I have a rule that automatically creates a new issue in a Jira project whenever a new Service Desk ticket is submitted. I also need to send an email that includes a link to the newly-created ticket. I've tried this setup, but the {{pipKey}} value is being set to the triggering issue's key, not the key of the issue being created (the initiative in the PHC Intake Processing project).

(I can't just rely on the notification scheme of the destination project; I need to notify a different user (or set of users) based on the request type of the service desk issue.

[Bill Sheboy]

Hi @Esther Strom 

When you create the issue, is there a way to uniquely identify it with JQL?  If so, could you use a Lookup Action to get the newly created issue and then use the key?

Given the way automation is scheduled to run asynchronously, this approach could have race track/timing issues when the create happens in whatever the rule engine considers partitionable, and so the issue may not always be found immediately after creation. 

Ideally, it would be great if the Create Issue action preserved/returned the key of the just created item to support use in follow-on rule steps.

Best regards,

Bill

[Steve Calvário]

Hello @Cristiano

Do you have any improvement ticket open or a date for this feature to be available on Jira Server ?

Regards

[Bill Sheboy]

Greetings, community!

Has anyone found documentation listing which issue fields and automation rule components are supported by Create Variable?  It seems like some fields/components cannot be saved in a variable.

Thanks!

[Esther Strom]

@Bill Sheboy sorry for the delay in the comment you posted on my question. In response, no, there's no way to uniquely identify the issue being created. I was hoping there would be something that's the equivalent of mysql's last_insert_id function.

[Bill Sheboy]

Hi @Esther Strom 

I just noticed {{createdIssue}} and {{createdIssues}} as the previously created issue, and the list of issues, created from within a rule.  Would those help you access the issue just made?

__Bill

[Bill Sheboy]

Greetings, community!  Quick tip: created variables do not appear to work as inputs to functions, such as:

{{issue.description.replace(myVariable, "my new text")}}

What happens is the variable evaluates to null and collapses the function, even when you add null handling.  Maybe there is something up with the typing of the created variables which does not allow them to be resolved.  I am submitting a defect for this so Atlassian has visibility of the issue.

Thanks!

[Darryl Lee]

@Bill Sheboy always finds the most interesting threads. (Also, I'm really behind on reading posts.)

I recently used Create Variable for a somewhat interesting use. I had an automation that previously would send an email/add comment/edit fields that was conditional on a Checkbox option being changed. (The checkbox was only editable in one transition.)

The customers wanted to add another potential condition - option that would be selected upon creation.

The upshot is that two different conditions could set off the *same* action. But I didn't want to have to define the action twice.

Enter Smart Variables. I used a If/Else-If conditions to check the two different cases, but instead of having to replicate the actions, I set a variable: {{actionrequired}} to yes if either case is met.

I made sure to have an Else condition at the end that set {{actionrequired}} to no, otherwise the rule might abruptly stop. (I can't recall if an empty Else is valid.)

And then I have a final If condition that just checks if {{actionrequired}} equals yes, and if so, run the actions.

IMPORTANT CAVEAT - I think it might be related to the AUT-517 non-deterministic bug, but I have to "declare/initialize" the variable before my first If condition, otherwise setting the variable within If conditions ends up returning a blank. I set it to no, but I think it would work setting it to anything. 

[Darryl Lee]

Another simpler use for variables if if you need to mail the same notification, but to different sets of users, based on a custom field. Instead of having to copy that notification block X number of times, you can use a smart variable (e.g. {{notifyees}}) that contains the list of email addresses (I made them comma-delimited, with no spaces), and then include that in the To: or Cc: field: {{notifyees}}

You can also use smart values this way in User Picker fields, like Assignee or Approver, but you unfortunately have to use the UserIds, which makes maintenance trickier. In this case I like to add an Audit Log entry above the Smart Variable setting so I know who actually got set to the variable.

Example:

[Mykenna Cepek]

While I appreciate the intention of this article, I think it can lead people who are new to Jira Automation to get frustrated with variables.

The example in the article shows a looping component, but it doesn't actually loop -- the JQL returns only one issue. The example then shows how a variable set in the loop will persist after the loop.

In general, this approach to use variables WILL NOT WORK, since most looping component usage is for actually looping multiple times. And as noted in the article comments, automation looping is non-deterministic.

The frustration goes well beyond this article, to include these ongoing related problems:

• The open ticket (AUT-517) for this non-deterministic behavior has not been addressed since it was created in Oct 2017.
• The documentation for variables (here) does not mentioned this problem.
• Using the "Create variable" component in a rule doesn't warn you about this either.
• Likely all other documentation on variables omits mentioning these critical problems.

Bill, I know you've made efforts to help make this better (such as this suggestion). But this is likely an architectural problem for automation and very difficult for Atlassian to solve. I feel this article muddies the waters, especially for new users.

An article clearly outlining what currently works and does not work with variables would be quite helpful. Variable scope problems and non-determinism will break reasonable procedural programming assumptions that many former developers (such as myself) bring to automation rule writing. I feel bad for those without a coding background trying to make rules with variables work.

I would consider writing such an article in the future. But part of the problem is the lack of clarity about exactly what the underlying problems are. I'm guessing from my empirical tests, and based on what I see others write about, that looping multi-threading is most of the issue. But is this true for all looping, only some looping situations, are there workarounds we don't know about, etc? Variable scoping discrepancies, and the way that audit logging also shows non-deterministic results, greatly complicate user-level experiments. I'd be left making best guesses, which undermines the certainty that solid algorithm design demands.

Please consider voting for these related open suggestions:

• JSWCLOUD-22690
• JIRAAUTOSERVER-22
• JIRAAUTOSERVER-384
• JSWCLOUD-22614

[Bill Sheboy]

Yes, and...

Everytime I believe I can solve a problem in a rule with a created variable, I run into another behavior such as they cannot be used as parameters to functions...collapsing to NULL for some design reason.  (I was just minutes away from creating an epic status bar rule, and...then I re-learned this doesn't work...again.)

https://jira.atlassian.com/browse/JRACLOUD-75659

Honestly, I am hoping to hear from someone on the Atlassian team about the valid use cases for this feature.  Variables seem to only work for simple set/get functions and conditionals, which could be accomplished without them, and string building.

On an unrelated note, and to save you rule-writers some time, please see this JQL defect which has impacts in rule conditions: the rule engine (i.e. the API) distinguishes between IS EMPTY and IS BLANK.  The impact is that if a field has ever been edited and cleared, it will never evaluate to IS EMPTY again.  Work-around: test for IS EMPTY and the field lengths for zero in your rules.

https://jira.atlassian.com/browse/JRACLOUD-74809

[Liam Harley]

I can not find this function,  Is it only on Jira Cloud?   

[Liam Harley]

I am new here, as the tag says.   I understand Create variables is not available in Jira server.   Shame!   I need this. : )     Is there a way to write to the log and and then retrieve the values?   That could be my work around.   I am currently writing to a Jira field but find even with data fetching my results are patchy.

[Bill Sheboy]

Hi @Liam Harley 

For Jira Server, I would suspect two current work-arounds are to write to fields/custom fields or to entity properties, followed by a Re-Fetch action.  Although using re-fetch could have its own side-effects and slow down automation rules.

Best regards,
Bill

[Deleted user]

Hi @Cristiano this does not seem to work with advanced branching with conditions. Any clue what might be the reason?

Here the variable is defined outside of a loop. Inside the loop there is only one value which will be true (and set the variable again) but the result is the updated variable is not accessible outside the loop

Side note, if anyone knows a better way to lookup values from a json array (like jsonPath) in automation rules please do share

[Bill Sheboy]

Hi @[deleted] 

If you review the comments for this post, you will see this technique only works when the branch has one-and-only-one issue, apparently determined at rule creation time.

Otherwise (according to the help documentation) the branch loop runs asynchronously, each variable inside is new/disposed of, and there is no guarantee when it will finish.  So your last log statement will never get the value.

Regarding your side note, have you considered using list and text functions to find your value with match/regular expressions?

Kind regards,
Bill

[Deleted user]

Hi @Bill Sheboy 

That's a bummer. Would be great if the branch loop had an option to wait for all items to process before proceeding. In my specific scenario it worked to just move all my subsequent logic into the loop but it would be great if it didn't need to be that way

I have tried using the list function to extract the specific value in the array I need, but the smart value list loop feature cannot access variables outside the loop. The value I need to compare with the list items is outside the loop hence this didn't work.

As for using regex to parse a json array, firstly it sounds computationally expensive and might fail if the json schema ever changes. Secondly, I think the best solution using text functions would be to do an indexOf() to find the matching value, then do a search either forward or backwards from that index (depending on if the ID field I'm looking for is above or below the Name field in the schema) to find the ID.

match() doesn't seem to have a parameter to define which index to begin the search. or be able to search backwards from a given index. Maybe a chain of substrings and indexOf()/match() might eventually get to the value I need but at that point its just a huge mess just to lookup a single value

[Bill Sheboy]

Hi @[deleted] 

Agreed: the string of list/text functions to solve this can be a mess, both to implement and to test.

One work-around others have tried for the create variable/branch limitation is entity properties or a custom field.  You could write to the property (or field) and then use a re-fetch action to access it later.  Of note: the re-fetch will dramatically slow down the rule.

__Bill