Mark,

Thanks for this. I’ll do some more thinking. Crossfuze is maybe something I’ll look into.

Thanks again,

Patrick

That does make sense, but unfortunately the ServiceNow security model around this doesn’t. You really have to go and start modifying additional ACLs and query business rules to make that happen. It’s not simple so I don’t have a written solution for it. If you’re interested in exploring a fully-featured knowledge management product for ServiceNow that addresses this (and a whole bunch of other KB issues) let me know and I can give you a demo of the Crossfuze KB turnkey solution.

This is great stuff. Just one question. If a user who isn’t logged in visits the kb_home.do page, they still see a list of all articles that have no role associated with them, regardless of the “Login required” value. I get this, because the UI macro only gets executed when a specific article is loaded. But do you know of any way of restricting what is publicly visible on kb_home.do i.e. so that role-less articles aren’t listed? (Hope that makes sense.)

Thanks a lot,

Patrick

I can’t blame anyone for being confused by that, I typed in the wrong field name! Thanks for pointing that out, I’ve fixed it up above so that it makes sense.

Thanks Mark,
It looks like it was a server cache issue. Others might also be confused with the create field Login required but the field name you reference is u_is_public (like my intern was). I have higher expectations of those utilizing jelly , but I would still adjust the instructions if it were mine :P.

Hey Andrew. This UI macro is automatically included by the ‘kb_view’ UI page so there’s no additional action necessary to make it work other than to create the macro. I’ve adjusted the documentation in step 2 above for future reference. It includes a wiki link that describes the out-of-box capability.

ServiceNow only allows you to separate KB content by role out-of-box. This is a problem that we’ve solved at Crossfuze in our Knowledge turnkey solution. It allows you to separate by role, group, department, company, location, and individual user. You can view information on our KB solution (and our other turnkey offerings) at the Crossfuze website. Let me know if you’d like a demo or further discussion.

http://www.crossfuze.com/solutions/turnkey-solutions

is there a way to seperate the knowledge base into two modules. Based on what group the user is in thats the knowledge base and articles they are able to see?

The whole point of using ‘kb_view_custom’ is to keep you from having to modify out of box code and breaking upgrades so you should never have to modify ‘kb_view’. The only thing I can say is to review the instructions and try again, or try setting it up in a demo instance and see if there are any differences. Regardless of what you do, the article will still be visible. The solution I’ve created here simply removes the article text and replaces it with a message indicating that the user can’t view a protected article.