Problem

When Jira and Confluence are co-located on the same Atlassian Cloud site, a platform-managed application link named "System Jira" is auto-created. This name is hardcoded and cannot be renamed, hidden, or replaced by admins — not via the UI, REST API, or any privilege level including system-administrators.

During hybrid, multi-wave DC-to-Cloud migrations, this creates a significant UX problem: the "System Jira" link appears alongside manually created application links (e.g., pointing to a DC instance) in the Jira macros pickers. Users can't distinguish between them, leading to confusion and incorrect macro mappings.

Current behavior

• PUT rename on the System link returns HTTP 500 regardless of privilege level — the rename is structurally blocked.
• DELETE succeeds (system-administrators only), but the link auto-regenerates within seconds with the same appId.
• The system and primary flags are server-controlled and can't be demoted or promoted via API.
• Non-system (manually created) links can be renamed freely.

Expected behavior

Admins should be able to customize the display name of the "System Jira" application link — or at minimum, the platform should allow setting a display alias — so that the link is distinguishable in the macro picker, Jira Macro Repair, and the Application Links admin page.

Use case

Enterprise customers running phased DC-to-Cloud migrations with both a System link (Cloud ↔ Cloud) and a manual link (Cloud ↔ DC) active simultaneously. Disambiguation is critical for correct macro repair mapping across migration waves.

Related: CONFCLOUD-72570 addresses a related but narrower gap (link naming within the Jira Macro Repair tool only).