Best way to share content with external 3rd party in Confluence w/o sharing internal content

Kylie Sommer

We are trying to organize training content within Confluence. We have certain training content we would like to share with partners and vendors, but would like to keep all other Confluence content internal to our Company users. 

 

If not able to set permissions based on email domain, (i.e. @shiphawk.com to view all; @Gmail.com to view spaces X, Y but nothing else) is there any workaround solution to do this without just making pages/spaces public?

 

Or should we not use Confluence to do this?

Kristian Klima_gtcuat

Hello @Kylie Sommer and welcome to the Community.

You can use Confluence for this. I am  

I'm gonna make a couple of assumptions here.

a) you don't want to make your spaces public (enable anonymous access for specific spaces)

b) you want to share the content with wider groups, not just with a couple of individuals. This rules out using Guests.

c) it's not viable to give your selected vendors/partners full (paid) Confluence seats.

d) Domain Shipwreck can see Content A, B, C, domain Carcrash can see Content B, C.

(There is a scenario, where you can make selected content fully accessible to anyone on the internet, so both Shipwreck and Carcrash can view that selected content).

Suggested setup

You're going to need the following apps

• Scroll Documents (optional, advanced scenario)
• Variants for Scroll Documents (optional, advanced scenario)
• Scroll Viewport

Scroll Viewport is an app that takes your Confluence content (any number and combination of space that you designate) and builds a static site for you (or mulltiple sites). 

• the sites are independent of Confluence, your native Confluence content remains in spaces that have no anonymous access
• you can choose whether to make a site(s) fully public or put it behind your company SSO or protect access by a token.
• you can have any number of sites public or protected

How does it pertain to your conundrum?

Well, you can create two Viewport sites, one with content from spaces ABC, the other with content from BC.

Then you simply set up your SSO environment accordingly and apply those settings to the respective Viewport sites. As a result, Shipwreck users will be able to access Viewport ABC, while Carcrash users will be able to access Viewport BC. Each of those sites can also have your own custom domain.

If you wish, you can create another Viewport site that will be totally public.

Mind, Viewport sites are independent of Confluence.

Your workflow would be as follows.

1. Create and edit your content in the respective Confluence spaces.
2. Once it's ready, use the Viewport app to rebuild the sites.
3. Done.

The optional apps allow you to create 'scroll documents', a virtual representation of content from one or multiple spaces. So you can create a 'scroll document' that contains only a section of a Space A and then define Viewport site to only use that scroll document to built a site (rather than entire space).

It gives you way more flexibility in working and arranging content.

As for Variants, this is conditional content territory. You can determine which pages (portions of a page) appear in which viewport site.

 

Disclaimer: I'm not working for K15t and I'm using all three apps (among others) to create Internal and Public doc sites from a single Confluence space. Internal is behind SSO, Public is public. It's an incredibly easy and efficient way to handle multiple audience docs from a single source.