Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Smart Values and Regex not working as expected

Robbin
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 22, 2025

Scenario
Email comes in to Service desk, raised a ticket, new ticket triggers automation to run.
Pretty standard scenario so far


Field 1
: Jon Doe
Field 2: 123456789
Field 3: Some other text here
Date 1: 26 September 2025

Expected output will go relevant fields (but for simplicity dumping it in to a comment to help debug)

Comment results:

Field 1: *: Jon Doe <- Not expecting the *:
Split 1 of Field 1: *: <- Not Expected
Regex: {{issue.description.match(".Field 1:*(.*)").Split(" ")}} 
What I would expect to work is below but for some reason does not work, unless I include a * after the :

- {{issue.description.match(".Field 1: (.*)").Split(" ").get(0)}} 
- {{issue.description.match(".ield 1:.(.*)").Split(" ").get(0)}} 

I'm pretty sure the 2 examples above should work, especially as it works for Field 3

End Split of Field 1: Doe

Works fine in the comments, but adding it to a custom field suddenly makes it Doe{Color}

where did this {Color} come from? 
Regex: {{issue.description.match(".ield 1:.(.*)").Split(" ").getFromEnd(0)}} 

 

I'm having a similar issue with Field 2

Field 2 output: *: 123456789

REGEX: {{issue.description.match(".Field 2:*(.*)")
Again i would expect {{issue.description.match(".Field 1:(.*)") or {{issue.description.match(".Field 2:.(.*)") to work but it just doesn't output anything.

 

Field 3 works perfectly for some reason
REGEX: {{issue.description.match("Field 3:.(.*)")}}
Outputs exactly what I expect

 

Date 1 also works perfectly and enters correctly in to a date field.
{{issue.description.match(".ate 1:.(.*)").toDate("dd MMM yyyy").format("yyyy-MM-dd")}}

 

 

 

Where am i going wrong?

I've tried various forms of regex that i know works else where, but i'm not getting result in jira or inconsistent results.

I've dumbed down the regex alot from what I initially wanted to use to just using greedy matching using the * options.

I have also checked for hidden characters and the email body itself is clean too, no hidden characters that could mess with the Regex.


Input: 
Field 1: Jon Doe
Field 2: 123456789
Field 3: Some other text here
Date 1: 26 September 2025

expected Output:
First Name: Jon
Last Name: Doe
Report ID: 123456789
Report name: Some other text here

Report Date: 2025-09-26

2 answers

1 vote
Bill Sheboy
Rising Star
Rising Star
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.
July 22, 2025

Hi @Robbin -- Welcome to the Atlassian Community!

First thing: there is no complete documentation for automation which states which regex syntax is / is not supported.  The docs indicate (with emphasis added by me) the "underlying implementation is based on Java's Pattern class", yet there is plenty of evidence in community posts of differences.  Thus, experimentation is key to confirm results:

  • start with the simplest expression that can possibly work, testing that fully
  • incrementally add to it for edge cases, etc.
  • backup to the prior expression if it stops working

 

Next, the match() function's use of regex does not handle newlines well.  I recommend one of these approaches, depending upon your scenario:

  • first split on newlines to reduce the scope the match needs to check
    • {{issue.description.split("\n").match("myregex")}}
  • or, replace newlines with nothing or spaces
    • {{issue.description.replace("\n", " ").match("myregex")}}
  • or, when newlines are needed but impede the match(), replace with a known value and set them back later
    • {{issue.description.replace("\n", "~~").match("myregex").replace("~~", "\n")}}

 

Finally, some rule actions can have racetrack timing problems, where a complex smart value expression may not completely evaluate before it is needed.  For example, dynamically generating JSON based upon a match().  The mitigation for this is to first save the match() result in a created variable, forcing complete evaluation, and then later split() the variable back into a list for usage.

 

Kind regards,
Bill

0 votes
Shawn Doyle - ReleaseTEAM
Community Champion
July 22, 2025

Hi @Robbin 

There are multiple differences in the regex that is working and the one that is not.

{{issue.description.match(".Field 1:*(.*)").Split(" ")}} 

{{issue.description.match("Field 3:.(.*)")}}

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events