Instead of maintaining many categories each with a limited set of keywords, the customer wanted to be able to use one category, containing a hierarchy of subcategories, each in turn containing the appropriate keywords.

In the Schema definition, for each field, that uses a category, it should be possible to select one of the subcategories as the root.  
When editing or creating a component based on this schema, the list of keywords should be limited to the keywords which are hierarchically below the configured subcategory.
When the field definition does not have a subcategory defined, it should use the default behavior, to show the full list of keywords for the category.


To mimic the requested behavior, keywords are treated as a subcategory. By selecting a keyword, it will be used as the Root element.
This alternative Root is stored with in the schema definition, as part of the field description.
Each field can have its own optional root keyword definition.

The implementation of this functionality consists of two CM GUI extensions.

The Schema Editor contains an additional control which allows the administrator to select a Root keyword.
This control is only visible when "Values will be selected from a List" and "Category" are selected

The Component Editor is extended to be Root Keyword aware and generate and show lists limited by this new root as can be seen in the two screenshots below


Finally here is an example of how the definition is stored in the Schema

<xsd:element name="subCategoryPG1" minOccurs="1" maxOccurs="1" type="category:SuperCategory">
<tcm:ExtensionXml xmlns:tcm="">
<RootKeyword xmlns="" Id="tcm:12-880-1024"></RootKeyword>
<tcm:Size xmlns:tcm="">1</tcm:Size>
<tcm:listtype xmlns:tcm="">select</tcm:listtype>
  • Thank you for posting this. At times we also felt the need for a similar requirement but never got around to implementing something practical. Would it be possible for you to share the "GUI Extensions" involved here?

  • , yes that correct, the editor can only see and choose below the selected subcategory, no escape possible.

  • The maintenance tasks saved would then include at least:

    - Creating a (new) Category versus a new "branch" in the existing category

    - Not needing to set a new Category to at least read for all users (since permissions are already set)

    - Slightly simpler synchronization across DTAP

    I think this means you also have trade-offs such as:

    - Higher chance for conflict between Keyword titles/names (which need to be unique, I believe)

    - Flatter granularity of permissions (and management) for managing these keywords

    I'd guess this would be a good fit for "system-wide" classification rather than Keywords meant to control editorial flow or display logic (e.g. checkboxes for navigational display).

    The closest editorial experience I could imagine to this without an extension would be to use the Tree view against a Category with nested keywords but the starting Keyword set as a default. The difference is it seems this solution wouldn't allow a user to select other "branches" of the "Super Category," right?

  •  for this customer, the main reason was to centralize maintenance, to ease that and to prevent unnecessary duplication, while exposing only the relevant part(s) to the editor.

  • I'm a bit confused as to why you want to group multiple Categories under a "Super Category" and then still constrain the Keyword Fields to those sub-Categories (which are now actually Keywords). I see that already hints at why: external taxonomy sync.  Was that also applicable for this customer? Or are there other reasons for their requirement?