Knowledge block - how does that work?

[Cristina Silva]

How does it work to use knowledge block when creating a new article? Is the concept similar to parent-child? And I guess knowledge block is a function you need to activate in ServiceNow? I would like to hear you experiences with using knowledge block and what the benefits are

[mbernste]

If you want to separate tech support knowledge from general knowledge, your best bet is to have two separate knowledge bases.  That's how we do it where I work.  What I use the knowledge blocks for is for routing instructions.  So, if a level 0 (end-user facing) article has routing information, I put that in a knowledge block that only support personnel can see when viewing the article.  It can be used to insert support-facing content in an article, but that can get a bit messy in terms of maintenance.

I haven't worked with the VA and knowledge blocks, but I would assume if the VA is in a group that can view a particular set of knowledge blocks, that it can obtain that information, however, you have to be careful as it may be possible for the VA to provide non-end user information to a chatter who is an end-user.

[RHolmes123]

Yes, I'd like to do that. The end user information will be created after the Tech Only is complete. We won't be using VA for Tech, so that aspect is a future challenge. 

I do need to learn how to add routing instructions, however. (assuming this is routing within SN related to block permissions, and not used as an example of a doc providing Network routing instructions and the techs who can see it) 

I like it though, what I'm understanding, is that I can set Knowledge Blocks to be visible to Tiers 0, 1, 2. Therefore, I can separate blocks of info visibility per tier within an article.

If I created an End User KB, and added EU info to it, it's good. The 2nd (or 3rd level) Tech KB's will use the KB's assigned (created for?) Tier 1 and 2, limiting 0's accessibility.  

I'll need to learn how to use the blocks, clearly. I don't expect you to answer all my questions, just hoping you see my hypothetical?

This all stems from this concern: 

https://www.servicenow.com/community/knowledge-managers/limiting-search-to-one-kb/m-p/2422025

(I am robynh007 and robynh123)

[Vickie Runyon]

Knowledge blocks do not separate knowledge bases for search. Knowledge blocks are just chunks of reusable content that 'can' have access separation or not - but only for the specific block, not the entire article.

We have been down both roads - separate knowledge bases and one knowledge base. Pros and cons to both.

Pros: easy to separate access to the entire Knowledge Base with User Criteria; easy for a knowledge worker to understand which KB is which and the expected audience for that KB; different templates; different knowledge blocks.

Cons: can lead to duplicate information - one issue can have content in each/every knowledge base leading to more maintenance keeping the content up to date; maintenance of multiple user criteria; maintenance of multiple knowledge blocks; cannot move articles from one KB to the other (if a custom template is used)

We have landed on using a single knowledge base with a custom template that has ACLs applied to several fields - meaning that the 'tech-only' content can be hidden from a non-tech reader. This also follows the KCS methodology of one issue - one article. We will have to recreate the articles that live in the current tech-only KB in the new public KB with the new KCS template.

We are not using Virtual Agent yet so I can't comment on how that will work.

The overall answer for you though is that Knowledge Blocks are not the magic bullet for the separation of access to content. You would not typically create a Knowledge Block for the body of an article since it would be unique information for that article only. Knowledge Blocks are meant for information that repeats in multiple articles, in my opinion. 

[RHolmes123]

Thanks Vickie, I appreciate it! Once I looked into the knowledge blocks more, I understand it's purpose. I think the ACL solution will be on list of things to check. If you can share a link on how to do that, awesome! If not, that's ok. Virtual Agent will likely end up calling on the End User topics, and the Tech only KB will need to be separate like yours. How did you do that? 

[Vickie Runyon]

Using ACLs to control access to fields in our custom knowledge template was a bit tricky to figure out but here's how I did it.  First, I created the custom template and defined all the fields. Then, I created an article using that template (all of this was done in DEV so as to not expose the article to all).  Then, I created an Access Control List (have to elevate role to Security Admin first) and a matching Role (which includes the groups that I want to have access to). Then, right-click on the field(s) that I want to limit access to and apply the newly created ACL. Repeat for additional fields. Test and verify by impersonating different users in different access levels to ensure that visibility is limited as desired.

Controlling access to a knowledge base is done with User Criteria. See User Criteria under Knowledge in the Filter Navigator in ServiceNow. We use groups to allow access to the tech-only KB. You can specifically grant Read or Write access with the criteria, allowing some of the team (or all) the ability to create or edit articles.