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

[PAWANK]

I complete agree with @Eoghan Sinnott Using the Read Criteria option of the Blocks when you have multiple groups of users with Contribute access, can become messy to manage and even to support the user queries / questions related to why they can't access something. We use the blocks only for the case where we want to "reuse" some content in multiple articles.

For example:

A generic "Reset Password Tips" knowledge block. Contains common advice applicable to all password resets. E.g. security best practices.
The following block content can be inserted in KB1234 and KB5678.
Never reveal your passwords to others.
Use different passwords for different accounts.
Use multi-factor authentication (MFA). 
Make passwords that are hard to guess but easy to remember.

[Vickie Runyon]

This doesn't necessarily apply to Knowledge Blocks but in our scenario, we have a single Knowledge Base that everyone can see. We built a custom template with separate fields for Resolution which are based on the team that applies the Resolution. We then applied ACLs to the fields so that only certain groups can see those fields.

We also use Knowledge Blocks but those are for standard blocks of text such as the escalation group name or the how to contact the Service Desk text that we always put at the end of the Self-Service Resolution field.

[Kristin J]

Thanks for the breakdown of how you're using blocks as well as providing/controlling Resolution steps. I appreciate that input.