Is there a way to override Confluence's anonymous settings and use a specific site as the Knowledge

[Jack Lee]

We are trying to enable the Knowledge Base of Jira Service Management for Virtual Agent. During this step, we understood that we need to lower the accessibility of Space to the "All logged-in users" level from "Only Confluence users."
https://support.atlassian.com/jira-service-management-cloud/docs/activate-or-deactivate-ai-answers-in-the-virtual-agent/#Activate-or-deactivate-Atlassian-Intelligence-answers

However, we realized an issue while attempting this step.
(https://ggnetwork.atlassian.net/wiki/spaces/RCQ/settings/permissions/anonymous)
This operation requires allowing global anonymous connections. (https://ggnetwork.atlassian.net/wiki/admin/permissions/global?tab=anonymous)

Since we use Jira and Confluence as our enterprise workflow management systems, we cannot turn off global anonymous access restrictions, a very secure option for simple PoC testing.
We want to use a temporary new space for PoC. Is there a way to supply the Confluence Page as a knowledge base to JSM without turning off the global security device?

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Anonymous access is done in two layers - global and space.

The global flag does not allow anonymous access to anything.  If you turn it on, no-one will see any more than they could see before.

You enable anonymous access in each space individually.  But you can not enable it if the global flag is "no anonymous access". 

And even if you turn the global on, add anonymous access to a space, and then turn off the global, the space will stop being anonymously accessible.  (It keeps the setting though, so it you re-enable the global, it'll become accessible again)

[Jack Lee]

Hi Nic,

Your explanation matches my understanding. I'm just wondering if I can make a case to circumvent the constraints or make an exception case.
In the current constraints, enterprise organizations can never enable the Virtual Agent's Knowledge Base function.

[Nic Brough -Adaptavist-]

Hi Jack, 

There could be a case to look at, but I will admit that I am very uncertain of it.  Not because I think you might be wrong, but because I am not sure I understand.

Enabling anonymous access globally in Confluence does nothing other than enable the space owners to allow anonymous access to their space.

I do not understand why this structure is a problem.  I am certain I am missing something.  

If you could help me understand, then the first question I would ask is why an enterprise cannot enable a Virtual Agent's Knowledge-base function.  What is wrong with that?

[Jack Lee]

Hi Nic,

The virtual agent requires the Knowledge Base Space to be open to "All logged-in users" or broader. I am guessing this is because the client authority of Slack or Virtual Agent should not have an equal or higher level than the confluence user.

I referenced the following part of the guide.

Before you begin, make sure:

• you have a knowledge base space linked to your project 
• your linked knowledge base space is set to All logged-in users under Who can view 
• your organization admin has turned on Atlassian Intelligence 

We created a space dedicated to the knowledge base for the agent and changed access levels of this space to anonymous reading, but the Virtual Agent is still not using knowledge base contents. Actually, there are no warnings or errors. Since the Virtual Agent keeps asking the same questions to determine intent, we assume it cannot access the knowledge base space due to the global anonymity setting.

[Jack Lee]

Enabling anonymous access globally in Confluence does nothing other than enable the space owners to allow anonymous access to their space.

I do not understand why this structure is a problem.  I am certain I am missing something.  

This is related to our policy. We will never enable anonymous access globally since all spaces in Confluence have confidential enterprise contents.

We can not check that anonymous access is restricted across 120 spaces one by one. Almost all spaces are controlled by delegated owners. We can not afford their mistake of opening their space. I guess that is the primary goal of the global anonymous blocking option.

Even in this status, we want to open only one space forcibly to evaluate the Virtual Agent. If it is worth operating, we might need a new organization.

[Nic Brough -Adaptavist-]

You need to enable the global anonymous access to enable any space to allow anonymous access.

That is indeed the whole point of the global flag - it is an absolute yes or no for your whole site.

You will either need a new Confluence service, or enable the global setting and then check every space is not anonymously accessible, apart from the one you need.

[Jack Lee]

I hope I explained our - or most enterprise organizations situation well: the nonsense of opening a global anonymity configuration to set up just one space for a virtual agent's knowledge base.
It is also ridiculous to create a separate new account with double pay for the Service Management system since we already have an account for all users who can manage knowledge base information.

So, I think a Service Management Virtual Agent with a Knowledge base is not an option for enterprise customers.

[Nic Brough -Adaptavist-]

It's completely the opposite, almost all enterprise customers I know of make use of Service Management Virtual Agents.

[Jack Lee]

Are their Atlassian Intelligence answers bound to Confluence Spaces as Knowledge Base?
Virtual Agent is an excellent interface, and I also do not have a problem using it as an issue receptor using intent recognition.
However, I can not find only how to bind space as a knowledge base for AI answers without degrading the security level.
If many companies succeed in operating this, can you share some best practices?

[Nic Brough -Adaptavist-]

Breifly, yes, the agents have access to the Confluence spaces, so that they can suggest articles from it.

You can't expect an agent system to suggest articles that it cannot read!

[Jack Lee]

So, our most apparent blocker of accessing the Virtual Agents Atlassian Intelligence Answer from Confluence Space is the global anonymity option.
In our scenario, we do not aim to answer questions from outside of the company. We want to answer questions from internal companions via Slack. Of course, they have access to the knowledge base directly. Atlassian Intelligence Search does not cause this kind of access problem. I guess the Virtual Agent can not forward the questioner's authority, which makes sense in common sense.
How did another company pass this wall? Did they allow global anonymous access? Or is there another workaround?

[Jack Lee]

I think there is a chance you are talking about a system recommending a knowledge base to the operator since you said: “suggest articles.”
I’m talking about a feature where the Virtual Agent automatically replies to the Slack channel from Atlassian Intelligence Answers.

https://community.atlassian.com/t5/Atlassian-Intelligence-Articles/AI-answers-in-Jira-Service-Management-Now-in-open-beta/ba-p/2461837

[Jack Lee]

I just found a way to attach images.
This configuration is where I am struggling.

[Nic Brough -Adaptavist-]

Yes, everyone enables anonymous access to the space(s) that they want the agent to work with.

[Viktoryia K_]

Hello @Jack Lee 

I also looked for information on this issue, but found nothing(

[Jack Lee]

Thanks for sharing the case, Viktoryia. 😥