Issue Summary

When a new Jira Service Management (JSM) project is created using the "Create with shared configuration" option from a source project, nested SLA priority targets are not replicated correctly. Instead of maintaining the grouped structure (where multiple priorities sit under a single JQL-defined goal), the cloning process "unrolls" every nested priority into its own standalone SLA goal row, set to "All matching priorities."

This behavior leads to a significant multiplication of the total SLA goal count in the destination project. In large-scale enterprise environments, this can cause the project to bypass the hard safeguard limit of 90 (or 120) SLA goals per metric, leading to potential performance risks such as indexing lag and SLA engine latency.

source Project A

Newly created project B

Steps to Reproduce

1. Source Project (Space A): Configure an SLA metric using grouped priority targets under a parent JQL goal (e.g., a single goal for "Incident" with nested targets for P1, P2, and P3).

1. Creation: Create a new JSM project (Space B) using "Create with shared configuration", selecting Space A as the source.

1. Verification: Navigate to Project Settings > Request Management > SLAs in Space B and inspect the cloned goals.

Expected Results

The destination project should retain the nested priority groupings from the source, ensuring the total SLA goal count remains identical and within safeguard limits.

Actual Results

The cloning converts all nested priorities into separate, standalone goal rows. For example, a single source goal with 5 priorities becomes 5 separate goals in the new project.

Workaround

Currently there is no known workaround for this behavior. However user can manually correct this behaviour by adjusting the SLA goals in the newly created project.