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:

{{issue.customfield_11195.asNumber.round}}

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

{{issue.customfield_11163.split(",").get(Index).trim}}

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?

[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

1. 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}}
2. This ensures it's an integer (your .round and .asNumber handle decimals nicely).
3. 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}
4. 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

[Trudy 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:

{{issue.customfield_11163.split(",").get(Index.asNumber).trim}}

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>