Managing data categories

In the previous sections, we looked at how we can limit access to Knowledge with object-level security, field-level security, and record types through profiles and permission sets.

If we want to restrict access to specific articles in a more granular way, we need to use data categories. By using these, we can categorize articles into a structured hierarchy of categories.

Let’s say our company sells products to North America, Asia, and Southern Europe. We may need to categorize our knowledge based on these macro-territories for specific countries (for example, power supply specifications change from country to country, as well as regulations).

Let’s define the data category structures:

• North America:
  • Canada
  • USA
• Southern Europe:
  • Albany
  • Greece
  • Italy
  • Spain
• Asia:
  • China
  • India
  • Japan

Articles may be linked to all the categories, to a subset of them, or none of them.

You can define data categories by going to Setup | Feature Settings | Data Categories | Data Category Setup:

Data Categories setup

You can have a maximum of 5 category groups and only 3 activated at a time, 100 categories in a group, 5 levels of nested categories, and up to 8 data categories from a data category group assigned to an article (as of summer 2019).

Categories are assigned on the right-hand side of the article page (if you can’t see the categories component, add it with the Lightning App Builder). From this component, we can select a whole group of category groups or single child categories, but not both.

Data categories can even be mapped to a case’s fields. We can do this by going to Setup | Feature Settings | Service | Knowledge | Data Category Mappings. This way, cases are automatically assigned to specific categories groups, thereby filtering knowledge articles to a greater extent.

One of the cool features of categories is that they can handle visibility at the profile or role level. But how does this work?

If a user doesn’t have access to a category (depending on their profile, permission sets, or role), they won’t be able to attach it to a case, and the Knowledge component won’t be able to suggest any of the articles in those categories. If an article has more than one category assigned to it, the user should be able to access to at least one category per group among the selected categories.

You can select the default category group’s visibility by going to Setup | Feature Settings | Service | Data Categories | Default Data Category Visibility:

Default Data Category Group Visibility setup

From here, we can define the following:

• All Categories (by default, all the categories are accessible)
• None (by default, no category is accessible)
• Custom (you can select default accessible categories, as shown in the following screenshot)

The following screenshot shows the Category Group Visibility edit form:

Default category visibility custom setup

That being said, you go to Profiles | Permission Sets | Roles to get a more granular category definition. When setting up roles, visibility is inherited by the child roles and, despite common Salesforce sharing behavior, we can restrict further access using roles. That’s why we can set the CEO role so that it has full access to categories while selecting different roles with custom or no access. If the parent role doesn’t have access to a category, then the child roles won’t be able to see them either.

The same configuration can be made at the profile or permission set level, but no inheritance is in place here.

It is not possible to restrict access to profiles. Please refer to Salesforce Help at https://help.salesforce.com/articleView?id=000268329&language=en_US&type=1 for more details.
 
 If you are interested in setting up Knowledge with communities, please refer to Salesforce Help at https://help.salesforce.com/articleView?id=networks_knowledge_access.htm&type=5.