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

[Peter102]

I question how much we have customised in our instance over the years but the scenario you described works for us. We have all fulfillers with contribute access to our IT knowledge base but if we use the can read to limit an article or block to a specific user criteria then this overrides the KB access to limit it further. 

It takes the narrower of the two (KB access vs article/block access). So yes, your scenario would work in our instance. If that is because my predecessor had to implement customisations, I'm not sure (but don't think so).

[Kristin J]

Thanks for the reply. I think you have a customization in place, based on what I've read in Docs, but that also means that it's technically doable. If my use case warrants it, we'd have to come up with a way to take the narrower of KB access vs. article/block access.

[Peter102]

Turns out we have customized it. I did some testing in a PDI and yes, the Contribute access at a knowledge base level overrides the can read/cannot read on individual articles.

[Peter102]

Found it, you need to enable the sys property glide.knowman.apply_article_read_criteria this will cause the articles can read/cannot read to override the knowledge base can read/can contribute. I just tested this in a PDI and it worked.