Blanket approval for "Viewer" access?

Question

We have a current site built in confluence today.  It requires granting access to view for each individual that clicks on the link.  Is there a way to set the site to be viewable by all that are Lilly-authenticated individuals?  If so, are there existing instructions on how?  Thanks in advance!

Martin Runge · Answer

Hi @Patrick Taylor,

Welcome to the Atlassian community!

I would check page restrictions first, because that is the most common reason a space-level grant has no effect. Restrictions beat space permissions, and they inherit down the tree, so one restricted parent can lock everything below it. You find them under Space settings > Permissions > Restricted pages.

Also worth being precise: "All Confluence users" only covers accounts that already hold Confluence product access, so it is not the same as all Lilly-authenticated people. The seat is the real gate.

Servus, Martin

Sami Shaik · Answer

@Patrick Taylor ,

@Arkadiusz Wroblewski A or B split and @Tomislav Tobijas questions are the right ones, so let me lay out the three layers behind "viewable by all Lilly-authenticated people", because each is a different switch in a different place and only one of them costs money.

Layer 1: can they sign in at all? That is your organisation's claimed domain and SSO in Atlassian Administration. If lilly.com is claimed and authentication policy sends people through your IdP, then "Lilly-authenticated" already means "has an Atlassian account managed by your org". Nothing to change here unless people are hitting a sign-in wall.

Layer 2: do they have Confluence product access? This is where the per-person approval you are seeing comes from. In Atlassian Administration → Products → your Confluence site, Product access decides who gets Confluence when they sign in. Turn on automatic access for your approved domain (or the default access setting for the site) and every lilly.com account gets Confluence on first sign-in, no approval queue (default groups and product access). This is the layer that consumes licences: each person who gains product access is a billable Confluence user, and the Viewer role in Confluence roles is a space permission level, not a licence type; a viewer still holds a seat.

Layer 3: can they see this site's spaces? Once they have product access, space permission decides visibility. Arek's answer is the mechanism: in each space (or the space template your admins use), grant All Confluence users → Viewer. Do that once per space and the individual grants stop.

If the goal is "everyone can read, but we do not want to buy 30,000 seats": Atlassian documents a route for people who have site access but no Confluence licence, called unlicensed internal access; it is tied to Jira Service Management (the "Use Confluence" permission in the JSM section of Confluence administration) and to the "unlicensed users" class in space permissions (granting unlicensed internal access). It is narrower than it sounds (read-only, and it assumes JSM is on the site), so read the KB before planning around it. Anonymous access is the other seat-free route and is the wrong one for internal content: it means the whole internet, and on role-based sites it is now controlled at site level.

So, in order: check Layer 1 is already true; decide at Layer 2 whether automatic product access for the domain is acceptable to whoever pays the bill; then set Layer 3 once per space. If the answer at Layer 2 is "no seats", the unlicensed route or Kris's publishing-site approach are the two honest options, and both are architecture decisions, not settings.

Tomislav Tobijas · Answer

Hi @Patrick Taylor ,

The question would be: where (and potentially how) are those users 'Lilly-authenticated'? I'm guessing those people don't have Atlassian licenses, nor are they logging in to any of the Atlassian apps you're using 👀

Also, are these users internal employees or some kind of external partners or customers? If we're talking about 'externals' potentially you could use guests feature, but this wouldn't necessarily correlate with the authentication you've mentioned. 🤔

Would be great if you could provide some additional details on those users, the current setup and whatever you can share so we can try and see the best course of action here.

Cheers,

Tobi