Genesys Cloud - Main

Hi everyone!

I'd like to share an idea for a potential improvement regarding Knowledge Base permissions in Genesys Cloud.

Imagine an organization with multiple Knowledge Bases, each one dedicated to a different department, team, or customer. In this scenario, it would be useful for administrators to define exactly which Knowledge Bases each agent can access.

For example:

• Agent A → Knowledge Base A
• Agent B → Knowledge Base B
• Agent C → Knowledge Bases A and C

This could be particularly useful in larger environments, where agents may work with different teams, customers, or business areas. Limiting access to only the relevant Knowledge Bases could make the experience more organized and prevent agents from seeing information that isn't relevant to their role.

My suggestion would be to introduce a permission or configuration that allows administrators to assign specific Knowledge Bases to users, roles, or groups.

I'm curious to hear how other organizations are handling this today.

Do you think granular Knowledge Base permissions would be useful in your environment? Are you currently using another approach to control which Knowledge Bases agents can access?

I'd love to hear how others are approaching this. 👇

This is a great topic and something that can become increasingly important as organizations scale their Knowledge implementation.

In larger environments, it is common to have multiple Knowledge Bases created for different business areas, brands, products, or even customers. As the number of Knowledge Bases grows, having a way to control which content is available to each agent becomes an important part of governance.

Today, organizations often need to rely on workarounds such as:

• Creating very strict naming conventions and content organization;

• Training agents on which Knowledge Base content applies to their role;

• Structuring teams and processes to avoid unnecessary exposure to unrelated information.

However, these approaches do not provide the same level of control as a native permission model.

A granular Knowledge Base permission capability could bring several benefits:

• Better governance and content management;

• Reduced cognitive load for agents by showing only relevant information;

• Prevention of accidental access to content that is not applicable to their role;

• Easier management of complex environments with multiple departments or customers.

A possible approach could be allowing Knowledge Base access to be managed through users, roles, groups, or divisions, following the same governance principles already available in other areas of Genesys Cloud.

I believe this would be especially valuable for enterprise environments with hundreds or thousands of agents and multiple lines of business.

Curious to hear how other organizations are managing this today. Are you using a different approach to control Knowledge visibility, or do you also see value in having more granular permissions?

Thanks for the detailed response! I completely agree, especially regarding governance as the number of Knowledge Bases grows.

I particularly like the idea of using users, roles, groups, or divisions to manage Knowledge Base access. Divisions could be especially interesting for organizations that already use them to separate teams or business areas.

I think the key point is that this would not only be about restricting access, but also about making the agent experience more focused. If an agent only works with a specific product, customer, or department, showing only the relevant Knowledge Bases could make it easier to find the right information and reduce confusion.

It would also be interesting to see this combined with the existing permission model, so administrators could have something like:

Division/Group → Assigned Knowledge Bases → Agents

That would make Knowledge governance much easier to manage at scale.

I'd definitely like to hear from others who are already managing multiple Knowledge Bases. Have you found a reliable workaround for this, or are you mainly relying on processes and training today?

Hi Joao Saraiva,

Great idea! Granular permissions by user, role, or group would be very useful in larger organizations, improving both security and the agent experience. This would definitely be valuable in our environment.

Thanks for sharing!

Hi, thanks for raising this - it's a valid gap.

As far as I can tell, Knowledge Base isn't currently a division-aware configuration object in Genesys Cloud (unlike Queues, Flows, Wrap-up Codes, etc., which can be scoped via Divisions). So there isn't an existing native mechanism to restrict which KBs an agent can see - happy to be corrected if someone has found a workaround.

A few points worth clarifying as the idea gets refined:

1. Granularity – per user, per role, or per group? Role/group-based tends to scale much better in larger orgs.
2. Enforcement scope – should this apply only to the agent-facing Knowledge panel during interactions, or also to KB management/admin views and Knowledge Suggestions/Predictive results?
3. Many-to-many mapping – your Agent C example (KB A + KB C) implies this needs to work as a permission set, not a 1:1 assignment, which is a fair but non-trivial ask architecturally.
4. Relevance side-benefit – scoping searchable KBs per agent could also improve suggestion accuracy in Knowledge Suggestions, not just be an access-control play.

If Divisions were extended to cover Knowledge Base as division-aware, that would likely be the most consistent way to implement this given how the rest of the platform handles object-level segregation - but that's a platform enhancement, not something achievable today with current permissions.

Thanks for breaking this down! I really like the idea of making Knowledge Base division-aware, especially since Divisions are already used to separate and manage access to other Genesys Cloud objects.

Regarding the granularity, I agree that a role/group-based approach would probably be more scalable than assigning Knowledge Bases individually to each user. It could also make administration much easier in larger environments.

For me, the main priority would be the agent-facing experience. If an agent only works with a specific customer, product, or department, being able to limit the Knowledge Bases available to them would help keep the search experience focused and avoid unrelated content appearing in the first place.

I also really like your point about Knowledge Suggestions and Predictive results. If the same scope could be applied there, I think the benefit would go beyond access control and potentially improve the relevance of the information presented to agents.

The many-to-many model also makes sense to me. An agent may need access to multiple Knowledge Bases depending on their responsibilities, so I don't think a 1:1 assignment would be flexible enough.

Overall, I think making Knowledge Base division-aware would be a very consistent direction for the platform. It would be great to hear if anyone has found a workaround for this limitation today.

Hi João,

Please post your idea on the Ideas Portal and share the link with us here so we can help support it by voting for it.

The Ideas Portal is the best place to share and promote suggestions like this.

Hi!

I've posted the idea on the Ideas Portal. You can find it here:

Allow Administrators to Restrict Agent | Genesys Cloud Ideas Portal

Thank you for the suggestion and for the support! I really appreciate it. 🙌

Divisional aware knowledge bases is something we have been pushing for, for a while. However we have recently been told it is no longer being considered. 

That's interesting to hear. I'd be curious to understand a little more about why divisional-aware Knowledge Bases are no longer being considered.

From an administrative and governance perspective, it seems like it could be quite valuable for organizations with multiple departments or lines of business.

Was there a particular technical or product consideration that led to the decision? I'd be very interested to understand the reasoning behind it.

Not had the feedback as yet but I am trying to understand the reason behind it.   

Got it. Well, I came up with a new idea, who knows, it might help bring this topic back!