Issue Summary

When configuring a Jira automation rule that uses the Send Slack message action, clicking “New Slack connection” does not reliably trigger the Slack OAuth / re-authentication flow if there is already an existing Slack connection for that user.

Instead, Automation silently reuses the existing Slack workspace connection/token, and creates another connection entry pointing to the same workspace. This behaviour makes it impossible for a user to switch the automation rule from one Slack workspace (e.g. sandbox) to another (e.g. production) using their own account.

This is particularly problematic for customers who:

• Initially configure automation against a sandbox Slack workspace for testing, and
• Later, need to update the same rule(s) to point to the production Slack workspace.

Due to the current behaviour, even when selecting “New Slack connection”, the rule continues to connect to the original sandbox workspace, with no OAuth prompt to select/authorise a different workspace.

Steps to Reproduce

1. Create a new automation rule and add an action to “Send Slack message“
2. It will ask to connect to a Slack workspace. Complete the steps.
3. Now, try to add a new Slack workspace by adding a new connection or removing an existing connection.

Expected Results

• When the user explicitly selects “New Slack connection” in the Send Slack message action, Jira Automation should:
  • Initiate a fresh Slack OAuth flow, or
  • At a minimum, allow the user to choose a different Slack workspace,
    even if a valid connection/token already exists.
• The user should be able to replace the existing workspace connection with a connection to a different Slack workspace (e.g. move from sandbox to production) without having to involve another Jira user or revoke tokens externally.

Actual Results

• No Slack OAuth popup appears.
• Automation silently reuses the cached token for Workspace A.
• A new “connection” is created, but it still points to the same original Slack workspace.
• The user can't connect this rule to Workspace B using their own account.

Workaround

Workaround 1: Use a different user (if available)

1. Have another Jira user open the automation rule.
2. In the Send Slack message action, they see the original user’s connection and an option to:
   • take ownership, or
   • create a new connection.
3. Ask them to create a new connection.
4. Because they don’t yet have a cached Slack token, the Slack OAuth pop-up appears.
5. They authorise the Atlassian app against the correct production Slack workspace.
6. The rule now uses this second user’s connection to the correct workspace.

Workaround 2: Revoke and reconnect

1. In Slack
   • Go to the Slack workspace where the existing connection is configured.
   • Revoke access for the Atlassian Connector (or relevant Atlassian Slack app).
2. In Jira Automation
   • Remove existing Slack connections.
   • Edit the rule and remove the “Send Slack message” action completely.
3. In Jira Automation (again)
   • Add the “Send Slack message” action back into the rule.
   • Since the previous Slack grant was revoked, the existing token is now invalid, so a Slack OAuth popup appears.
   • Use this popup to authorise the Atlassian app against the correct production Slack workspace.