Using Jira automation to extract text from email created work item to update the work item Summary

Question

I have read thru several posts in the forum and can't quite find the answer to my situation...

Scenario:

I have specific platform tools that create Jira work items by sending an email. The body of the email becomes the work item description, and I create a custom work item summary based on the platform and some other minor info.

Want:

What I would like to do is to extract some of the data from the email body/description and use it as part of the work item summary.

Steps that I have taken:

I have updated the Jira automation that creates the work item based on the email subject to include the creation of a smart value variable that is populated by some regex that is then supposed to update the work item summary, but it is not.

Automation steps:

* Create work item if:* Summary contains "whatever, whatever"

* Create variable:* Variable name: investigationType
* Smart value: {{issue.description.match("created investigation\s+(.+?)\s+on\s+\d").first}}

* Edit work item fields:* Summary: whatever, whatever - {{investigationType}}
* Labels: X, Y1, etc
* Priority: High

* Done

I have tested my regex multiple times on regex101.com with success, but for some reason the summary is still not being updated.

Sample of work item description/email body:

"SIEM created investigation CrowdStrike Falcon - A process attempted to delete a Volume Shadow Snapshot on 20 September, 2026 1:12 PM.

The priority of this investigation is Medium.

The investigation was triggered by detection rule Attacker Behavior Analytics > CrowdStrike Falcon - A process attempted to delete a Volume Shadow Snapshot in response to activity from Win11 Test."

The result should be that the work item summary is updated to be:

"whatever, whatever - CrowdStrike Falcon - A process attempted to delete a Volume Shadow Snapshot"

Questions:

* What am I doing wrong?
* Do I even need to create a variable?
* Is there something wrong with my regex?

Any/all help would be appreciated.

Thank you

Gor Greyan · Accepted Answer

Hi @Larry Hofmann,

Welcome to the Atlassian Community!

You don't actually need a variable for this, although using one can make testing easier.

The main thing I would change is the regex. From your sample description SIEM created investigation CrowdStrike Falcon - A process attempted to delete a Volume Shadow Snapshot on 20 September 2026 1:12 PM try extracting everything between “investigation ” and “ on ”

This should return- CrowdStrike Falcon - A process attempted to delete a Volume Shadow Snapshot. Then your Summary can be- whatever, whatever - {{issue.description.match("investigation (.+?) on ")}}

Before updating Summary, add a Log action containing only the match() expression and check the Automation audit log. That will confirm whether the extraction works independently of the Edit work item action.

Atlassian also has a KB specifically showing this approach with a description.match().

https://support.atlassian.com/jira/kb/extract-content-out-of-description-and-summary-with-regex-and-automation

Gabriela - LeanZero · Accepted Answer

Hi Larry, I rebuilt your rule on a test site with your sample text, and the piece that breaks it is the .first at the end. The regex itself is fine. With a single match, match() already hands back the captured group as plain text, and calling .first on that returned nothing in my test, so the variable was empty and the summary came out as "whatever, whatever - " with nothing after the dash. Atlassian's text-functions doc describes that split: match() "returns the first (and only one) matching regular expression group", and only when there are several matches do they come back as a collection you can iterate. Dropping .first from your own expression gave the full "CrowdStrike Falcon - A process attempted to delete a Volume Shadow Snapshot" text, same as Gor's version.

If your summary doesn't change at all, not even the fixed part before the dash, I'd look at the audit log next, because that points at the condition or the trigger and not the regex.