nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Using variable in get() statement

john.monteith

I am not posting a lot of screen shots or other visuals, because I felt this is a pretty straightforward question that has nothing to do with workflows or the like. Please let me know if I'm mistaken after reading, always willing to admit I was wrong

I have the following fields:

Index - number field (custom field 11195)
Approvals needed - text field that contains a comma separated list (custom field 11163)

I have an automation rule that updates the Index field, incrementing it by 1 as issues are transitioned from one approval step to the next. That is working just fine.

The problem is occurring when I try to access a value in the text field via an index number. I have tried creating a variable called Index:

to ensure that the value is an integer and not a decimal, etc. I then was trying to use that variable like so:

to access the value at the correct index position.

I have tried tweaking the statement in multiple way. My overarching question is:

Is it possible to use the .get(n) statement with a variable being the value of n?

Accepted answers

Bill Sheboy

Hi @john.monteith

Short answer: This symptom is caused by data typing, and possibly smart value naming, problems, and can be solved with a "helper variable" to make the get() work. Skip ahead to the end if you just want the answer without the "why".

Why This Happens

Your expression is running into documented and undocumented challenges with value types and lists:

There is a built-in smart value named {{index}} which only exists when iterating a list. I recommend not using any field names or variable names which could collide and cause uncertainty in rule processing.
Custom fields with a number type can store floating point or integer values, and most smart value functions only accept an integer, with the exception of long-format math expressions and...
There are two versions of the get() function: the get() for most lists only accepts an integer value, and the super-helpful get() with the lookup table actions which can dynamically figure out the correct value: text, number, smart value expression, etc.
Putting some of those ideas together, we encounter the undocumented thing: smart values expressions usually, but not always, preserve the type of the first smart value encountered, particularly in function parameters. And thus your number field stays floating point even though round, floor, or ceiling is added to the end.

How-to Workaround It

A workaround I discuss in this article is using an empty, helper variable to force the expression to an integer. For example:

action: create variable
- variable name: varNull
- smart value: {{null}}
get the value from your field using the other field as the zero-based index

{{issue.customfield_11163.split(",").get(varNull.length().plus(issue.customfield_11195.floor)).trim}}

How that works is:

When varNull is created, we use a non-existent smart value of {{null}}, creating an empty string of zero length
When we get varNull.length() the first type the function "sees" is an integer, to which we may now add other values
And so we add the other custom field with a floor function to retain the integer typing
Finally using that integer value in the basic, list get() call

Kind regards,
Bill

All comments

Trudy P Claspill

Hello @john.monteith

I don't have a solution, but I wanted to share what I tried.

My first thought was that the problem is all variables are stored as strings, and get() couldn't cope with a string as its parameter

You may be assigning an integer value to your variable named Index, but when you then use Index it is evaluated as a string.

So my suggestion was going to be to try this:

But I tested that out myself using Log actions to print out values:
{{issue.Summary}}
{{Index}}
{{Index.asNumber}}
{{issue.Summary.split(",").get(1)}}
{{issue.Summary.split(",").get(Index.asNumber)}}

The values that printed were:
a, b, c
1
1
b
<nothing>

The_Earl

Howdy,

Directly NO, it is not possible to use a smart value variable (like {{Index}}) as the index parameter in the .get(n) method within Jira automation rules, the feature request for this can be seen at the link below MAKE SURE TO ADD A VOTE:

OOF community wont let me post a hyper link so ..... this is what ya get
- AUTO-1313

However I was playing around with this a bit and pretty sure property entity is gonna be your friend here, a little more complex but a decent workaround.

To store the index value in an issue entity property (in JSON format), then reference that property's value within the .get() method. Entity properties act as a temporary storage layer that allows the value to be resolved correctly during evaluation. Here's how to implement it step by step, tailored to your example (assuming Index is derived from {{issue.customfield_11195.asNumber.round}} and is guaranteed to be a non-negative integer within the bounds of your split list):

Step-by-Step Workaround

Create the Index Variable (as you're already doing):
1. In a "Create variable" action (or branch), set:
  1. Variable name: Index
  2. Variable value: {{issue.customfield_11195.asNumber.round}}
This ensures it's an integer (your .round and .asNumber handle decimals nicely).
Store the Index in an Entity Property:
1. Add a "Set entity property" action after creating the variable.
  1. Entity: Issue
  2. Property name: Something temporary like tempIndex (you can clean it up later if needed).
  3. Property value:
    1. Not sure if you need Wrap it in JSON for proper access like this:
      1. {"value": {{Index}}}
    2. Or just hit it wuit the smart value like this:
      1. {{Index}}
    3. I tried both and both seemed to work ... SHRUG?
2. This stores the integer value (e.g., {"value": 2}) on the issue.
3. You can see the values you have set using API via a get on the following endpoint:
  1. GET
    /rest/api/3/issue/{issueIdOrKey}/properties/{propertyKey}
Use the Property in Your .get() Expression:
1. In your subsequent action (e.g., "Edit issue," "Log action," or another variable), use:
  text
```
{{issue.customfield_11163.split(",").get(issue.properties.tempIndex).trim}}
```
2. This resolves the index from the property (issue.properties.tempIndex evaluates to your integer, like 2), accesses the list element at that position, and trims it.
3. Test tip: If the list index is out of bounds (e.g., Index=5 but the split list has only 3 items), it will return empty—add a condition to check {{issue.customfield_11163.split(",").size}} > {{Index}} first.

This approach looks like it should work reliably for dynamic indices, even in branches or iterators, as long as the property is set in the same rule execution. If your lists are very long or the index comes from complex math (like random selection), you can extend it by storing multiple values in a single JSON property (e.g., {"index1": {{Index}}, "index2": {{AnotherVar}}}) and accessing them separately as well as adding in delay and re-fetch actions between calls to space it out and avoid race condition scenarios.

Hope this helps ya

peace out,
- The Earl

Bill Sheboy

Hi @john.monteith

Why This Happens

Your expression is running into documented and undocumented challenges with value types and lists:

There is a built-in smart value named {{index}} which only exists when iterating a list. I recommend not using any field names or variable names which could collide and cause uncertainty in rule processing.
Custom fields with a number type can store floating point or integer values, and most smart value functions only accept an integer, with the exception of long-format math expressions and...
There are two versions of the get() function: the get() for most lists only accepts an integer value, and the super-helpful get() with the lookup table actions which can dynamically figure out the correct value: text, number, smart value expression, etc.
Putting some of those ideas together, we encounter the undocumented thing: smart values expressions usually, but not always, preserve the type of the first smart value encountered, particularly in function parameters. And thus your number field stays floating point even though round, floor, or ceiling is added to the end.

How-to Workaround It

A workaround I discuss in this article is using an empty, helper variable to force the expression to an integer. For example:

action: create variable
- variable name: varNull
- smart value: {{null}}
get the value from your field using the other field as the zero-based index

{{issue.customfield_11163.split(",").get(varNull.length().plus(issue.customfield_11195.floor)).trim}}

How that works is:

When varNull is created, we use a non-existent smart value of {{null}}, creating an empty string of zero length
When we get varNull.length() the first type the function "sees" is an integer, to which we may now add other values
And so we add the other custom field with a floor function to retain the integer typing
Finally using that integer value in the basic, list get() call

Kind regards,
Bill

john.monteith

Thanks for the detailed explanation of why this solution works, and yes it did work. The insight into how Jira handles certain tasks is very helpful.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud