Extract part of actual sprint name for Issue summary/name

Heinrich Bärhausen

After switching from Jira Data Center to Jira Cloud, we’re having a problem with an automation rule that no longer works.

In every sprint, one team has a story for checking updates to the systems in use.

As soon as this story is completed and marked as “Done,” the rule creates a clone in the next sprint.

The rule’s naming convention is our problem. It always uses the same name, with the sprint’s sequential number appended at the end.

Example: The story is called “Check the Update,” and the sprints are named according to the pattern “Team-Done-2026-12, Team-Done-2026-13.”

This results in story names such as “Check the Update – 12,” “Check the Update – 13,” and so on.

And that’s exactly where the problem has been since we switched to the cloud. We’re unable to extract the last two digits of the sprint name.

Depending on the Smart Value setting, the automation either uses all sprints from the previous clones as a basis and then enters “Check the Update – 10,9,12, 11,13,” or it extracts nothing at all.

We’re deliberately following Jira’s sequential process. That means first cloning, then moving it to the sprint in the next step, and finally changing the name. So Jira should know the story’s current sprint.

Sami Shaik

Hi @Heinrich Bärhausen , two things are happening at once here, and both are Cloud behaviours rather than a broken rule.

1. The Sprint field is a list, and the clone carries the history.
On Cloud, an issue’s Sprint field holds every sprint the issue has been in, not only the current one. Clone work item copies “all field data possible”, so the clone starts life with the original’s sprint history, and then Move to sprint adds one more. That is why {{issue.sprint.name}} prints “10, 9, 12, 11, 13”: you are printing the whole list.

Pick the latest one explicitly, then cut the number off the end:

{{issue.sprint.last.name.substringAfterLast("-")}}

last is the latest sprint, and Atlassian’s own Cloud automation KB uses exactly {{issue.sprint.last...}} for issues that have been in more than one sprint. substringAfterLast("-") turns “Team-Done-2026-13” into “13”. If you want the full “2026-13”, use substringAfter("Done-") instead.

Cleaner still: in the Clone action, add the Sprint field and leave it empty so the clone starts with no history. Then after Move to sprint the list has one entry and last is just belt and braces.

2. Your Edit step is reading stale data.
By default {{issue}} inside a rule “contains the same values as when the flow originally triggered”; it is not refreshed after your own actions. So even with the right smart value, the rename step can still see the sprint list from before the move. Put a Re-fetch work item data action immediately before the Edit work item step, inside the same branch that handles the cloned issue (“most recently created work item”). That action exists for exactly this.

Suggested order in the branch on the new issue: Move to sprint, Re-fetch work item data, Edit work item (Summary: Check the Update - {{issue.sprint.last.name.substringAfterLast("-")}}).

I have not run your exact rule, so check the audit log once after the first Done. If the summary still shows a list, post the audit log line and the branch type you used and I will look again.

Refs: Automation actions: Clone, Re-fetch work item data, Text functions: substringAfterLast, List functions: last, Cloud KB using issue.sprint.last .