Sitecore Content Hub Best Practices – Part II

In part two of this blog series, Gaurav Agarwal, Sitecore Solutions Architect and five-time Sitecore MVP, shares best practices for Sitecore Content Hub projects, focusing on tactics to utilize while creating schema, taxonomy, and other related fields on Content Hub.

If you missed Sitecore Content Hub Best Practices – Part I, we highly recommend reviewing that before this. 

Illustrations depicting Sitecore Content Hub Best Practices

Conditions in Sitecore Content Hub Schemas

Conditions play a very important part in creating schema. Conditions need to be created meticulously so that they don’t produce a load on the Content Hub graph.

Some key points to consider:

  • Conditions can be applied on the schema field level or member group level to show/hide fields on a particular page. For example, if we have multiple categories and want to show “field A” on category “ABC,” only then would you apply conditions.
  • More conditions create performance issues, when Graph rebuilds this can delay graph rebuild or create issues sometimes.
  • Instead of applying conditions on the field or member group level, a page should be created. Pages can be created based on condition. A page can be created by going to Settings > Pages >
Screenshot of the Sitecore content management system dashboard highlighting the 'Pages' icon for website page management, with other CMS features surrounding it

 

As I stated above, we can apply conditions on the member group level and schema field level, so in the below screenshots you can see how to apply these conditions. 

Member group level condition

Interface of a product management system showing 'Main' navigation tab, configuration options, and a popup for assigning user group level conditions.

 

Field level condition

Backend interface for editing member information with options for conditional access settings and a dropdown menu to assign user groups to products.

 

Creation of Member Groups within Sitecore Schemas

When we create a schema, we need to create several fields which are then managed in member groups. Member groups are a combination of several types of fields.

The properties and relations you assign to an entity definition are called members and they are grouped in member groups. An entity definition consists of one or more member groups.

A few things to consider while creating member groups in schema:

  • A member group in a schema can have multiple fields.
  • A member group can have fields (String, Boolean, Integer, Option List, Taxonomy, or Relation, etc.)
  • Be sure to create the member groups before you create the individual members.
  • Try to create fewer member groups as well as merge different members altogether if they are of similar type.
  • Try to have less than 100 member groups; more member groups can slow the schema UI.

Taxonomy vs. Option List in Sitecore Content Hub

In Content Hub, selecting the right field is critical. There are two options to create a selection list as well as the options of single select and multi-select.

The two options are Taxonomy and Option List.

Both have their associated pros and cons, so make a selection based on your project’s specific requirements. 

Taxonomies

  • You have a long list of values: use taxonomies when you have an extensive list (however, we recommend you avoid exceeding 300 values). For controlled vocabulary lists containing fewer than 50 values, use option lists instead.
  • You need to set security rules based on these values: option lists cannot hold security properties. Use taxonomies when you need to apply security model rules based on values from your taxonomy.
  • You need to inherit your values: option lists can be facets in search pages but cannot inherit from your data model family tree.
  • You need to keep more information than just the values: option lists cannot hold more than the value of the controlled vocabulary on itself. You can extend taxonomies with additional properties because they are schema definitions. For example, you can add a description. Option lists are not schema definitions but simple data sources without any additional properties.
  • You need a hierarchy that’s deeper than five levels: option lists have a limitation in the number of sub-levels you can create. They can hold a simple five-level hierarchy but not more. Taxonomies have no limits on the number of hierarchy levels they can carry.

Option List

  • You have a short list of values: use option lists for controlled vocabulary lists with fewer than 50 values. In this case, option lists are more powerful than taxonomies. Do not use taxonomies for short lists of values.
  • You need to display this data only on the detail page and the entity’s search component: if the data is only displayed directly on the entity itself, use an option list.

So, in short, if you need security or need a hierarchy of more than five levels and need more than 50 values then go with Taxonomy otherwise go with Option list. For more reference, you can check the official Sitecore Documentation.

Programmer working on code across multiple screens, reflecting a focused coding session in a modern development environment.

 

Work with a Sitecore Development Partner

Could your business benefit from a partnership with a Sitecore agency? Look no further than Americaneagle.com. Our certified developers and architects are here to help you make the most out of your Sitecore instance. Contact us today at [email protected] to learn more about our Sitecore development services


About Author

Gaurav Agarwal, Sitecore MVP
Gaurav Agarwal is Sitecore Solutions Architect and four-time Sitecore MVP. Gaurav has several years of experience implementing Sitecore solutions and integrations, he also has experience with Sitecore Commerce as well. In his initial job time, he used to work as a full-stack developer.


Featured Posts