How do reader groups work?

We're often asked if it's possible to have content for different readers in the same knowledge base. For example, maybe you have both internal support documentation as well as customer-facing product documentation in the same knowledge base. Or, you might have a knowledge base that contains categories for different departments or teams in your organization.

If you'd like to segregate content--or display different content to different readers--you can do this by using Reader Groups and the Restrict to Groups option in the content itself.

There are three basic steps in this process:

• Create reader groups
• Assign readers to those reader groups (set their Reader Group Access by creating/editing an individual reader, bulk-creating new readers, or bulk-editing existing readers)
• Restrict content to reader groups

Let's say I have a category of documentation called KO Product Support, and that category is restricted to a reader group called KO support.

If I'm a member of KO support, I'll see this content in the table of contents, search, etc.

If I'm not a member of KO support:

• I won't see the KO Product Support category in the table of contents or on the homepage
• If I type to search, the typeahead search won't show me any of the articles in KO Product Support
• If I complete a full search, the search results won't show me any of the articles in KO Product Support
• If someone gives me the direct link to an article in KO Product Support, I'll only see a message that I don't have access to that content

In short, the content isn't something I can find or discover on my own, and even with a direct link, I can't access it.

Can I set reader group restrictions for an entire category?

Yes! If you restrict a category to certain groups, all of that category's content (subcategories + articles) will automatically inherit the reader group restrictions you set. We call these Inherited Restrictions. Any reader groups that an article or subcategory is inheriting are shown in the Inherited Restrictions section.

There's also an up arrow icon in the Restrict to Groups list to identify inherited groups:

The up arrow after the group name indicates this is an Inherited Group

Can I override restrictions inherited from a category?

No. You can add additional groups in the Add More Restrictions section, but you can't remove any of the inherited groups.

If you do add a group in the Add More Restrictions section, a reader must belong to that group as well as the Inherited Restrictions group. See the following section for more information on that behavior!

If an article or category has multiple group restrictions selected, what happens?

The short answer is: it's a little complicated.

You might have multiple groups selected by:

1. Having multiple groups displayed in the Inherited Restrictions section
2. Having multiple checkboxes selected in the Restrict to Groups section
3. Having one or more groups in the Inherited Restrictions AND the Add More Restrictions section

For the first two scenarios, the behavior depends on your knowledge base's Reader Group Logic settings. You can check or update the Reader Group Logic by going to Settings > Security and checking the Reader Options section:

Two Reader Group Logic options are supported: Inclusive and Exclusive.

• Inclusive: Readers can see content when they belong to at least one designated group (multiple groups are treated like an "or")
  • Example: An article is restricted to groups "Apples" and "Bananas".
    • Reader in Apples group only: sees the article
    • Reader in Bananas group only: sees the article
    • Reader in both Apples and Bananas group: sees the article
    • Reader in the Pineapples group: won't see the article
• Exclusive: Readers must belong to all designated groups (multiple groups are treated like an "and")
  • Example: An article is restricted to groups "Apples" and "Bananas".
    • Reader in Apples group only: won't see the article
    • Reader in Bananas group only: won't see the article
    • Reader in both Apples and Bananas group: sees the article
    • Reader in the Pineapples group: won't see the article

For the third scenario:

• Having one or more groups in the Inherited Restrictions AND the Add More Restrictions section

The Inclusive/Exclusive logic still applies within each of those sections, but the sections combined are treated as a combination: a reader must belong to at least one of the Inherited Restrictions groups AND one of the Add More Restrictions groups.

Example: An article has Inherited Restrictions for the Administrator group and has the KO Product Support group checked in the Add More Restrictions section:

• Reader in Administrator group only: won't see article
• Reader in KO Product Support group only: won't see article
• Reader in both Administrator and KO Product Support groups: sees the article
• Reader in KO Product Support and HR groups: won't see the article