Smart Values and Regex not working as expected

[Robbin]

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

[Bill Sheboy]

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

[Shawn Doyle - ReleaseTEAM]

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:.(.*)")}}