Knowledge blocks feel illogical...

[Kristin J]

Hello! I'm sure there has been plenty of talk about this over the years, but I'm struggling with the logic of using blocks within a support department knowledgebase. If all members of the department are set to contribute to a knowledgebase, then they can't use blocks to control display for the individual teams in that department because everyone sees everything.  I'm using Select user criteria for a knowledge block as my reference, as well as based on what I see in my instance.

For example, imagine I have a knowledge base and the Help Desk department has Contribute. Within the Help Desk department there is Tier 1 and Tier 2. When building a troubleshooting article, it might be cool to use a Block to display steps for a Tier 1 agent vs. steps for a Tier 2 agent. But all Blocks show in the article, because of the knowledge base level contribute.

Is this accurate, and what is the fix for my situation? Or is this just not how blocks are intended to be used, and I can only use them with end-user criteria?

Thanks to those who have gone before me and may know the ways! 😎 

Kristin

[Kristin J]

Thanks for the update on this. Very helpful for me making a decision whether to stay with using a block only for the "reusable" case for me, or for visibility based on group, etc. Cheers!

[mbernste]

We use separate knowledge bases for each tier of support.  I'm guessing your company has a restriction preventing you from doing that?

[Kristin J]

No, we don't have a restriction, per se...but we are small and our Tier I/Tier II can overlap. My example was a hypothetical because my real example was harder to articulate without context 🙂

[Eoghan Sinnott]

Hey Kristin, 

I think one of the main purposes of using the Knowledge Blocks is for having reusable content that may appear in more than one knowledge article. So if there's a specific piece or block of text that you need to add to multiple articles, you can create a block and add that instead. That way, if a change is needed you just edit the block and then all the articles get updated as a result. 
I know we do on occasion take advantage of the Read Criteria option of the Blocks to "hide" information from certain users. But as you said, that does get a bit messy when you are giving multiple groups of people Contribute access. As far as I'm aware, Out of the Box, Can Contribute access on the Knowledge Base level will supersede any Can/Cannot Read Criteria.

Regards, 

Eoghan

[Kristin J]

That's true...the reusable is awesome and makes sense for sure. I'd seen an example in an SN workshops where they built an article on Vacation Policy, and then the blocks were used to display different information for different groups. This is essentially what I wanted to do, but came up against the visibility thing.

We are an internal support group, so we are our own customers :-). If I created an article on vacation policy as per the SN example, it would work for all non-support people, but then a support agent would look at that and see 7 different blocks haha.

I may need to consider usage of blocks for the "resusable" factor only, and not to control visibility.