How to Map Links Between External Shares
Overview
External Share allows you to share Confluence pages externally. The cross-space link mapping feature enables you to map links across different spaces, so that a shared page can include and correctly resolve links to content located outside its own space.
A mapping connects two external shares and works in both directions.
Once two shares are mapped, links between their spaces resolve for external readers of either share, so there is no need to create the mapping twice.
By linking external shares for each space, you can share interconnected content from across your Confluence instance, provided there is a valid business need and the appropriate shares are configured.
Prerequisites
The shared page must already contain links to content from other spaces.
You must have share edit permissions to create or edit space mappings.
How to Set Up Cross-Space Link Mapping
Create the target share first
Before mapping, make sure the target page in the other space is actually shared. Navigate to the target space and create an External Share for the page(s) you want to make accessible.
Share your main page
Go back to the main page you want to share in your current space. Clicking to create this share will generate the link and unlock its configuration options.
Map links to another space
Click the Spaces tab in the link details window.
Select the target space from the first dropdown menu.
A second dropdown will appear. Select the active share from that target space.
Click to add the mapping.
Mapping Limits
Each share can have at most one mapping per space.
Several shares in the same space can each have their own mapping, but a share that is already mapped toward a given space cannot be used for another mapping toward the same space. Shares that are unavailable for this reason are not shown in the share list.
Result
When an external user opens the shared page and clicks a link pointing to content in a mapped space, they can view the linked content without encountering permission errors.
Important Note on Access & Permissions
A mapping routes links to the other share, it does not widen what that share exposes. A page in a mapped space opens for an external reader only when it belongs to the shared page structure of the mapped share (the shared page itself or one of its child pages) and meets that share's own criteria, including its security settings and any label restrictions. Pages outside that structure stay unavailable, exactly as they would without the mapping.
Example Scenario: Marketing Campaign Sharing
A marketing team wants to share a “Q1 Campaign Overview” document with external partners. This page lives in the Marketing space, but it includes a link to performance reports stored in the Analytics space.
Without cross-space mapping: External users can see the campaign overview but cannot access the linked analytics page.
With cross-space mapping: Once the Marketing share and the Analytics share are mapped, partners can follow the link from the campaign page to the analytics report, provided that report is part of the Analytics share's shared page structure.
Comments
thank you for the background! I added under overview
Approval: Green Team | Docs approval
Status: Approved
Yoonjeong Bae - Started:
Feb 9, 2026 6:02:41 PM TZ: Europe/WarsawTomasz Lewandowski - Approval:
Feb 10, 2026 1:54:28 PM TZ: Europe/Warsaw- action taken by delegate: Teodora Vasileva - Added a comment on the Jira work item. Overall it looks great :)Kamil Zarychta - Consent:
Feb 11, 2026 8:53:10 AM TZ: Europe/Warsaw- Please check my comment, there is no need to trigger another approval after it has been applied
Hi Yoonjeong Bae ,
Could we update this page so that the cross-space mapping behaviour is easier to follow for customers? Four points, all verified against the current implementation.
1. A mapping works in both directions
The page currently reads as if mapping were one-way ("map another space to a share"). In fact a mapping connects two shares symmetrically: once it is created, links resolve in both directions, so readers of either share can follow links into the other space. This is worth stating in the Overview, because customers otherwise assume they have to create a second, mirrored mapping.
Suggested sentence for the Overview:
A mapping connects two external shares and works in both directions. Once two shares are mapped, links between their spaces resolve for external readers of either share, so there is no need to create the mapping twice.
2. "Each space can be mapped to only one share" is not accurate
The limit applies per share, not per space. A single share can have at most one mapping to a given space, but several shares in the same space can each have their own mapping. What is not possible is reusing a share that already has a mapping toward that space.
Suggested replacement for that bullet:
Each share can have at most one mapping per space. Several shares in the same space can each have their own mapping, but a share that is already mapped toward a given space cannot be used for another mapping toward the same space. Shares that are unavailable for this reason are not shown in the share list.
3. What a mapping actually makes available
The page says the linked content is accessible "as long as the target content is shared", which customers read as "any page in the mapped space". The mapping only routes the link to the other share: the linked page still has to be part of that share's shared structure and satisfy that share's own rules. This is the most common source of questions, so it deserves its own paragraph.
Suggested wording, as a note after step 3 (Result):
A mapping routes links to the other share, it does not widen what that share exposes. A page in a mapped space opens for an external reader only when it belongs to the shared page structure of the mapped share (the shared page itself or one of its child pages) and meets that share's own criteria, including its security settings and any label restrictions. Pages outside that structure stay unavailable, exactly as they would without the mapping.
4. One sentence in the Overview can go
"This mechanism was originally introduced to support organizations that want to share Confluence content with internal users who do not have Atlassian accounts, while still allowing them to navigate seamlessly across multiple spaces."
This is historical background rather than guidance, and it narrows the feature to one audience. The use case is much broader, so I would simply remove the sentence.
Happy to review the updated wording before it goes live.
Thanks,
Kamil
That is why I believe it would be worth adding information that, using the cross-space mapping mechanism, once a share is created for each space that should be exposed from the instance and properly linked, it becomes possible to share pages from virtually the entire Confluence instance - provided there is a business need for it.