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 Reader Groups. 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 Viewing to Reader Groups list to identify inherited groups:

Inherited Reader Groups will have an up arrow in the Add More Restrictions section

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 reader 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 Reader Groups. Refer to 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 having:

1. Multiple groups displayed in the Inherited Reader Groups section.
2. Multiple checkboxes selected in the Restrict Viewing to Reader Groups section.
3. One or more groups in the Inherited Reader Groups AND the Add More Restrictions section.

For the first two scenarios, the behavior depends on your knowledge base's Reader group logic settings.

To view and update this logic:

1. Go to Security and access > Security settings.
2. The Reader group logic is in 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 Reader Groups AND the Add More Restrictions section

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

Example: An article has Inherited Reader Groups for the KO Authors Only group and has the Owlcademy MC Students group checked in the Add More Restrictions section:

• Reader in KO Authors Only group only: won't see article
• Reader in Owlcademy MC Students group only: won't see article
• Reader in both KO Authors Only and Owlcademy MC Students groups: sees the article
• Reader in KO Authors Only and Contractor groups: won't see the article