External and internal labeling for knowledge articles

[Magnus Hovik]

Hi! Has anyone experimented labeling a knowledge article internal or external? Either through a custom solution or some other clever way.

Background: We currently have two knowledge bases per customer (we're a consultancy). External base (usually about 80% of the articles) and internal base. Only the external base is connected to the Service portal. This if fine but i'd love to have only one knowledge base with the option to mark something as internal, and not have them show up in the customer-portal. Having two knowledge bases is more administration, as we have lots of customers etc.

[Magnus Hovik]

We use only one template (KCS) for IT-support and would love to keep it that way. But good idea elsewise!

[T_Dockery]

We differentiate the Self-Service, Service Desk, and Technical Support (Level 2/3) articles using color-coded icons. A rectangle icon is placed at the top of each page to help agents quickly identify which articles can be shared with end users and which are intended for Service Desk or Tech Support.

• Green rectangle with "Self-Service" white text in the box. 
• Red rectangle with "Service Desk" text.
• Dark blue rectangle for "Technical Support."

These color icons enable agents to quickly determine the appropriate category of the article without needing to check the specific Knowledge Base it belongs to.

[Magnus Hovik]

Cool! Would you mind sharing a screenshot of what that looks like?

[Magnus Hovik]

Here is a working thought created in PDI: Label an article with "External" or "Internal" in the "Visibility" and create a workflow that adds a specific user criteria based on that. Internal status removes Guest User from criteria...something like that.

External

Internal

[DaneTurner]

Hey Magnus! This has been a challenge and issue for me during our implementation so hopefully this helps.

You can add a required dropdown field on each knowledge article called "Visibility" with options like Internal, External, and Partners.

Then you can build a Flow Designer flow (or a Business Rule) that dynamically updates the "Can Read" user criteria based on the value in that field. For example:

• If Visibility = Internal, we remove Guest users from "Can Read"
• If Visibility = External, we add them

This way, authors don't need to mess with user criteria at all. They simply pick the visibility label, and the system handles access for them.