Kentico Kontent is a feature-rich platform with lots to like and plenty to discuss. The roadmap is ambitious, the team is responsive, and new and exciting features are being released several times a year. It should be easy to pick the most noteworthy or exciting features, but my experience working with clients through the adoption of Kentico Kontent has made some of its most subtle features the ones that stand out to me the most.  

The concept of headless content service is still very new to a lot of people. The benefits are compelling, but the approach is so fundamentally different that much of our time goes into theory, training, and breaking habits ingrained by years of traditional Web CMS platforms in the course of any given project. Once we’re all comfortable with HOW to think about your content differently, understanding and leveraging the specific features of the platform tend to come very easily. To me, that means that the features of Kontent are so nicely aligned with the whole philosophy of the platform that they’re entirely intuitive for a user once they’ve become comfortable with that philosophy. The less attention a feature gets before it’s adopted and comfortably used, the more I like it.  

Snippets 

Most content platforms support the concept of attribute inheritance. The idea of eliminating redundant management and leveraging relationships in your content is so intrinsic to the headless approach; it’s a no-brainer that you’d want to be able to do that with your content types as well. Even Xperience – Kentico’s more traditional DXP platform allows for page types to inherit the fields of another page type.  

Snippets are Kontent’s approach to the same idea, and it’s not groundbreaking that it exists, but I love the way they executed it. Snippets are a part of your content model, but it’s separated from your content types. Think of snippets not as smaller content types inherited by larger content types, but – just as the name implies – re-usable groupings of fields that can be included in any content type as a pre-configured “snippet.”-. Suppose you create a snippet with all of the fields to build out an address. That can then be added as a single selection to any content type that needs address information, and any update to the snippet is made to any content type that inherits that snippet.  

All this without cluttering your actual content type list with “sub-types” or “base types” that are never actually used for content. It’s simple, clean, and I’ve never had to explain to a new user what some content type is and why they should never actually use it for anything.  

Taxonomy Groups 

Again, taxonomies aren’t new. They’re essential, and in some way or another, nearly every platform has them. Here again, Kontent’s Taxonomy groups stand out to me based on the restraint the Kentico team showed in their implementation. At first glance, the feature seems underwhelming. Still, they resisted the temptation to rely on rigid approaches that would have hindered the flexibility they allow for deciding the best taxonomy for each use case. There are no tag clouds, hierarchical categories, or anything like that. You can have as many taxonomy groups as you want, and each taxonomy group can have as many different taxonomy terms as you like.  

This can be leveraged for all kinds of purposes that may not be immediately evident, including audience targeting, topical categorization, access control, and distribution channel management. The simplicity keeps things open-ended and flexible, with just enough structure to be useful without getting in the way. 

Collections 

Collections is a feature that’s entirely separate from the content model and focused on the editor user experience and governance. When creating any new piece of content, it can be added to a Collection. Users can be given access to all Collections, a single Collection, or any grouping of the available collections. This means that if a team is only responsible for a certain subset of content, then that’s the only content they have access to when they log in. It streamlines the user experience for content editors and improves governance.  

From a content strategy perspective, though, the beauty of Collections is what it doesn’t add. If you wanted to achieve the same kind of governance and content ownership without Collections, you essentially have two options: 

• Create multiple identical content types in a single project so that you can limit user access to the version of the same content type that’s intended for their team (e.g., Legal Team Article, HR Team Article, Marketing Team Article). 
• Create a project in Kontent for each team’s content.  

Both of those approaches bring a lot of complications to the whole project. They also force you to introduce organizational hierarchy and governance concepts into your content model, create unnecessary duplicate content types that have to be kept in sync, and hinder the ability to share content across groups and channels easily. With Collections, you can let your content model be driven purely by your content.  

Content Groups 

Content Groups is the ability to create different groupings of content elements within a single content type. Each content group shows up as a separate “tab” on the content editing interface for a given content type. Rather than a single long list of fields on a content type, you can focus, for example, on just content; then maybe another tab is just for supporting attributes like URL Slug and SEO Metadata. Another could be target audiences and topical taxonomies. 

That’s a much nicer editor experience already, but you can also limit permissions of any role only to see certain content group tabs on a content type. This means that while a Subject Matter Expert may only see the fields necessary to write an article, the Marketing Specialist that’s next in line in the workflow can have access to the additional tabs to manage taxonomy, metadata, or other attributes specific to marketing and channel distribution that the content writer doesn’t need to be concerned with.  

In my mind, this feature carries water for a lot of other features across the platform. I might like the ability to group taxonomy groups to easily differentiate between persona/audience taxonomies, access management taxonomies, topical categorization taxonomies, etc. When those can be added into different content groups, though, the Taxonomy feature can stay very simple. The same is true of roles and permissions. I might otherwise want a more granular permissions model, but it doesn’t matter that a Subject Matter Expert role has access to edit the entire content item if they can only see the grouping of fields they should access.  

And just like Collections, this feature allows you to keep your content model driven by your content. Instead of breaking a single content type into multiple types so you can limit exposure of certain attributes to certain roles, you can use content groups and avoid letting concerns of governance complicate your model. 

Web Spotlight 

Strictly speaking, the Web Spotlight feature in Kontent isn’t subtle or stealthy. It’s a stand-out feature in every sense of the word. But the reason I like it is still in the way that it accomplishes its goals without disturbing your core content model.  

Headless content architecture is intended to allow you to manage your content completely agnostic of where or how that content will be displayed so that it remains just as easy for that content to reach eyes on a mobile app, wearable device, or printed brochure as on your website. Though the reality remains-- the website is still the primary distribution channel for most organizations initially making the transition into headless. There’s often a valid desire to retain more direct control over that channel. Web Spotlight allows you to manage a hierarchical structure of content specific to your website, providing more direct control over navigation, layouts, and in-context editing than you would otherwise see in a headless platform.  

It’s a powerful solution to a valid need in its own right, but the approach here is very well thought-out.  It supplements the solution without requiring any structural changes to your content types, in most cases. Your model can stay clean and intuitive, driven by the needs of the content alone, and equally suited for a social media post as a web page. 

That rounds out my top 5 Stand-Out features of Kontent, heavily biased by my passion for content strategy. The consistency of approach and priorities across the platform is refreshing. It makes adoption that much easier, and from the point of view of someone responsible for onboarding and training clients, that’s something that can’t be understated.