When it comes to getting some kb articles visible to unauthenticated (public) users, I found advice that looks basically like this:
- Navigate to Knowledge > Administration > Knowledge Bases.
- create a knowledge base to make it public.
- Go to the Can Read section or tab and remove any entries from the list.
Everyone gets read permission on all articles in that knowledge base. - In the Application Navigator's Filter navigator field, enter sys_public.list and press enter or return.
- In the Page column, look for page named kb_find.
- For kb_find, change the value in the Active column to true.
- In the Page column, look for page named kb_view.
- For kb_view, change the value in the Active column to true.
- As a public user, try <instance>/kb_find.do or try directly the permalink to your kb
But I found this has some usability trade-offs that my Service Desk knowledge authors did NOT like. After a short period of testing, they specifically did not like the consequences of step #8 above.
Our scenario was that once-upon-a-time, in the past, we made one public knowledge base, following those instructions above. But recently we created a new "How to access your apps" knowledge base with articles scoped for 'Any user'. We emailed permalinks for articles in this new knowledge base to new company onboarded users. But the links don't work if you're not logged into Servicenow, and they don't prompt you to login. Instead they display the "You don't have sufficient privileges" error message.
I realize now that we don't want kb_view to be made public, I would rather clone that UI page to something like, "pkb_view" and make the clone public. The consideration for me is that after kb_view is made public, a user who has a "permalink" for any non-public KB article must be logged in for the link to work. If you make kb_view public, its no longer behind a wall, so the page no longer prompts an unauthenticated user to login. Instead it moves on to evaluation of user criteria, which won't evaluate properly (because not logged in, can't check roles/groups etc.) This results in the "not sufficient privileges" message to a user, when all they need is to login. It should have just prompted for login and then taken to the link. But that behavior is broken after you change kb_view to public.
So the decision to make a knowledge viewing page (such as kb_view) public should be made with special consideration on how you will handle "permalinks". I chose to clone the "kb_view" UI page to "pkb_view" and make the clone public. Then I had to adjust how 'Copy Permalink' works, because that action is shown near the bottom of every KB article. By default, the 'Copy Permalink' action generates a link that includes '.../kb_view'. To customize how this gets handled, you can modify the KBViewModel script include, adding an override property and method like shown below:
permalink: this.getPermalink(this.knowledgeRecord.number),
getPermalink: function (number) {
var kbId = this.knowledgeRecord.kb_knowledge_base;
if (kbId == 'e1e48e93db54ae90209ca04913961911') //sys_id of my public knowledge base
return ("/pkb_view.do?sysparm_article=" + number); //pkb_view is my custom public UI page
else
return ("/kb_view.do?sysparm_article=" + number); //default UI page
},
If you did decide to make a custom public clone of the kb_view UI page, the code snip above is an example of how you could make the 'Copy Permalink' action generate a different hyperlink for the public knowledge base, while leaving kb_view for the others. Again, for me, the reason to do this was because I didn't know how to achieve having kb_view as public, but make it still prompt an unauthenticated user to login. Therefore I made a public page for one specific public knowledge base, and the regular kb_view page still used for the rest of them.
The result of this setup is two-fold:
1) Anyone making kb articles for the public knowledge base, if they click 'Copy Permalink', will get a link on the public UI page, pkb_view. This link will work for public, unauthenticated users, and will never prompt for login. If you need to make links to each other among your public kb articles, that permalink will give you what you need.
2) When someone is making articles for regular non-public knowledge bases, where user criteria contains in-platform checks like roles or groups, that person will click 'Copy Permalink' and get a link to the normal UI page, kb_view. Those links will work for a logged in user, and will prompt for login if not already authenticated.
If anyone knows a solution that combines the two benefits, let me know!
