Show Smartlink on Dashboards or Change IP requester

[Luisa Di Domenico]

Hi there!

My team works on the discovery and design process of demands using a space in my organization, while the development team works in a different space within another organization.

I created a dashboard to track the open demands in the other organization, and I would like to show the demand's status in that organization on this dashboard. However, the dashboard does not support smart links, displaying only the issue URL from the other organization.

To work around this, I considered asking the other organization to allow cross-organization issue linking. However, I hit the same wall since the dashboard still does not support smart links.

Another solution I found was creating an automation that fetches the status of the issue entered in a custom field (manually filled with the other organization's issue URL) and inserts that status into another field. The automation would run a few times a day to keep the field updated. However, for this to work, the other organization needs to allowlist Jira's IP address, and I am running into issues doing this due to their security policies.

I would like to know if there is any other way to solve this problem—specifically, allowing me to view the status of the issue from the other organization on my dashboard. Is there a way to make the IP making the request be my organization's IP instead of Jira's IP?

Any suggestions?

Thanks!

[Jean Horn]

Hi @Luisa Di Domenico !

That is a tricky cross-organization synchronization challenge! Since dashboard gadgets don't render Smart Links or resolve cross-org issue statuses natively, you’re hitting a common wall with Atlassian's security boundaries.

To answer your direct question about IP addresses: No, you can't force Jira's outgoing Webhook/API calls to originate from your own organization's static IP. Jira Automation runs entirely on Atlassian's cloud infrastructure, so those requests will always come from Atlassian's public IP ranges.

Here are a few cleaner alternatives you might want to consider to bypass the allowlisting pain:

1. Use an API Gateway / Proxy Function: Instead of calling the other Jira instance directly from Jira Automation, set up a lightweight middleman (like an AWS Lambda, Cloudflare Worker, or Azure Function) hosted under a static IP that their security team *can* allowlist. Your Jira Automation triggers the proxy, and the proxy safely queries the other organization.
2. Dedicated Marketplace App: Tools like Exalate, Backbone Issue Sync, or Issue Sync are built specifically for cross-organization or cross-instance syncing. They handle security, status mappings, and background sync natively without relying on raw IP allowlisting.
3. Inverted Automation (Push instead of Pull): If the other organization's security permits, ask *them* to create a webhook/automation that pushes status updates to your Jira instance whenever an issue changes, rather than having your instance reach into theirs.

Hope this gives you a good path forward! Let us know which approach works best for your setup.

[Luisa Di Domenico]

Hi, Jean! Thanks for answering. I will try the 3rd option first, I believe it wouldn't be a problem for them. Thank you very much!

[Sami Shaik]

Hi @Luisa Di Domenico , @Jean Horn is right on the core point: you cannot pin Jira Cloud's outgoing calls to your own organization's IP, and her three alternatives are all workable architectures. But before you build a proxy or change direction, there is a simpler documented route worth putting in front of the other organization's security team, because the problem may be how the request was framed to them.

The request should not be "allowlist Jira's IP address." No such single IP exists, which is exactly why security teams push back. The request should be: allowlist Atlassian's published outgoing connection ranges. Atlassian maintains an official, machine-readable list of the IP ranges its cloud products use, and it includes a dedicated Outgoing connections section, the much shorter list meant precisely for firewalls and allowlists receiving traffic from Atlassian, which covers automation and webhook egress: https://support.atlassian.com/organization-administration/docs/ip-addresses-and-domains-for-atlassian-cloud-products/

Three things that usually satisfy a security review:

1. The list is published and versioned, available as JSON at https://ip-ranges.atlassian.com/ so their team can consume it programmatically and stay current instead of maintaining a static entry. The same site includes a filter tool to narrow to egress ranges only.
2. Scope the real control to the credential, not the IP. An honest point their security team will appreciate: those egress ranges are shared by all Atlassian cloud tenants, so the IP allowlist proves the request comes from Atlassian's infrastructure, not specifically from your organization. The authentication that identifies you is the account whose API token your automation uses. So pair the allowlist with a dedicated service account in their instance, granted browse permission only on the specific project your dashboard tracks, and put that token in your automation. IP narrows the door, the credential decides who walks through it.
3. Time-bound and review it. Offer them a periodic review of the account's access, which turns a one-time exception into a governed integration.

If their security team still declines shared-range allowlisting as policy, then Jean's routes are your fallback, and I would try her inverted push option first (they push status to you), since it keeps their security posture fully in their hands and needs no allowlist at all.

One small premise check on the dashboard side: you are right that dashboard gadgets do not render smart links today, so some form of field-based status copy is the realistic way to surface the other organization's status on your dashboard, whichever transport you choose.