Store content

This page is a part of the Content modeling guide which you should follow sequentially from beginning to end.

This page explains what options for creating, storing, categorizing, and managing content you can find in Xperience by Kentico.

Before you start building your Xperience project, you need to carefully consider different ways you can store content. The business use cases you’ve identified during content modeling sessions will help you choose the most suitable approach for storing data.

In each of the following sections, you can read about the benefits of a particular approach and find links to relevant pages in our documentation:

Where to store your content

From a high-level perspective, you can look at creating and managing content in Xperience in two different ways:

Content is created

Content is managed






The Xperience database serves as the single source of truth for all content (e.g., various marketing materials, company-specific information, or product-related documents).

Before editors start producing content, developers must prepare relevant data structures (content types) in the administration.





Depending on the project requirements, customers often opt into combining storing options. They keep part of their content inside of Xperience and part outside.

The content they manage outside of Xperience usually comes from business- specific external systems, e.g., various external systems, such as global statistics databases, ERP or PIM solutions for managing product catalogs.

They synchronize this external content to Xperience using custom-built functionality that polls the source’s API and brings the data to Xperience.

We’ve commonly seen many variants of these options across different Xperience projects.

  • The system uses custom process which creates corresponding content objects in Xperience. At the same time, Kentico editors can manage (read, update, and delete) this data in Xperience and synchronize their changes with the origin.
  • If editors need to display some content in their applications, they reference the content stored in the third-party solution.
    For example, a reference to statistics objects (a codename) or products (SKUs) makes this data available for display across different Xperience-driven applications. Developers then ensure the data is styled and updated properly.
  • The third-party content is automatically displayed in predefined areas in the applications, for example, on websites. The third-party data is part of the website implementation, and editors cannot opt out from displaying this content.
Note that the last two options introduce several competing content management systems within one setup which can cause complications. For example, when editors find a mistake in the published content, finding out in which system they need to fix this content may be challenging.

Recommendations – Creating and managing content in Xperience

  • Storing and managing content directly in Xperience is recommended for most projects.

    • It ensures a single source of truth for content distribution across different channels. Moreover, editors know where the content for which they are responsible resides.
    • It prevents synchronization errors with third-party integrations and ensures that editors always have the latest version of the content available in one place.
    • We recommend storing content in Xperience if editors want to leverage online marketing features, such as content personalization or segmenting your audience to contact groups for various marketing activities.
  • If you need to display content from a third-party solution in an Xperience project:

    • We recommend building a custom bi-directional content synchronization tool that automatically updates the data across different systems automatically.
    • Implementation partners should provide sufficient project documentation that helps editors and marketers locate and efficiently manage their content.
    • Your editors should manage their content in the production environment using the default Xperience publishing workflow.

Consider your content from three different perspectives

There are different perspectives from which you can look at your content; each has nuances, pros, and cons. To simplify modeling content in Xperience, we recommend considering the following perspectives:

Structured vs. Unstructured content

  • Unstructured content contains data and instructions on how the system should display this data. In Xperience, for example, editors author unstructured content in email channel applications or the Page Builder in website channel applications.
  • Structured content keeps the content data separated from the design information in the database. In Xperience, this content is authored in the Content hub and on the Content tab in website channel applications.

Content from the presentation perspective

  • Navigable content items allow visitors to view the content item as a whole, such as a page under a URL on a website or on an app screen.
  • Reusable content usually serves as a building block for navigable items; visitors will never see the reusable content by itself.

Marketing potential of the content

  • Reusable content items are presentation-agnostic and usually highly structured. Marketers can reuse the same content item in different channels, such as in various places within a website or in other channels, for example, on a microsite or in an email.
  • Single-channel content items are usually strongly aligned with their presentation on a specific channel. Editors create this content as ad hoc as they need. As a result, they often tie the content to its design, for example, by using of Rich text WYSIWYG editors. Making the content dependent on a single channel often makes this content difficult to maintain, modify, and reuse.

Digital content and marketing channels

Marketing channels refer to platforms, tools, and strategies businesses use to communicate with their end consumers, suppliers, partners, and other business entities.

Digital marketing channels include a main site and campaign microsites, social media, emails, organic and paid search, or distributed content. Every channel offers various options to tailor marketing efforts according to specific goals and audience preferences.

In the past, businesses kept their marketing content separately for each specific channel. When a marketer wants to promote a campaign, they usually copy the campaign assets from the website to other platforms like email or social. Modern digital experience platforms like Xperience by Kentico help marketers by removing unnecessary work.

Marketers can store all their marketing content within one solution. Using the same familiar interface, they can orchestrate the distribution of their content to their digital channels directly from within Xperience.

Current version of Xperience by Kentico natively supports distributing content into a website and email channel. Support for building multi-channel experience will be released in coming months. 

Content in Xperience

In Xperience, all content is based on content types. You already know that a content type is a blueprint that defines data structure, functionality, and behavior for all content items that editors create from this type. Based on this definition, reusing content requires storing it in a presentation-independent manner, i.e., in a structured format.

The following diagram shows an overview of the storage options in Xperience.

Levels of abstraction in data storage

Use Content hub for reusable content

Xperience by Kentico comes with the Content hub application for storing reusable content. You can think of the Content hub as of a centralized repository where you create and keep all your marketing content you want to use – and potentially reuse it across multiple communication channels.

In Content hub, editors create items using content types with fields where they input data. The editing forms create a unified editing experience, and adding content in the content hub feels like filling an online form.

Content type editing interface

Because the Content hub is channel agnostic, editors do not see what the content will look like once it’s displayed, for example, on the company website. They can focus on the quality of their content rather than getting distracted by how the content will look.

Reusable content types from the data perspective

Content types in the Content hub store data in a structured format where fields corespond to database columns. Developers define content types in the Content types application.

When developers create content types, they configure:

  • Fields that define the data structure of the content type.
  • Editing form layout that creates the interface editors use to create and modify the content items.
  • Usage of the content type:
    • Reusable content types are building blocks of reusable content meant to be linked together to form further content.
    • Content types for pages are used in website channels to form pages.
    • Content types for email are used in email channels to form emails.

Developers use the Content types application and define the data model of the website. They create content types based on the project’s business requirements using easy-to-use admin UI consisting of form fields or ready-made form components.

Managing content type fields

The content type is stored in a coupled database table; its fields represent database columns. For example, KBank’s News content type can have a coupled table named KBank_News and columns defined as NewsTitle, NewsSummary, or NewsText.

Reusable field schemas

In version 28.2.0, Xperience introduced reusable field schemas that offer an alternative approach to modeling content types in the product. The current iteration of the feature is primarily admin UI driven. Future plans include full retrieval and filtering API support. As the feature develops, expect best practices described in this guide to change, reflecting newly introduced options. See the product roadmap for upcoming improvements related to reusable field schemas.

Find out which types Xperience comes out of the box in the Data type management . You will also learn how to customize the out-of-the-box set i f you need to support a different data types.

When creating the field names, we recommend combining the content type’s name with the field name, for example, BenefitDescription, ArticleName, or ProductTitle. Developers can access the field’s values through <contentType>.Fields.<Name> property, for example, page.Fields.NewsTitle. Determining the name of the type within the property name will ease some development situations. For instance, in SQL JOINs, you won’t need to use aliases to disambiguate between columns from two or more tables, such as News Title and Product Title.

Use the built-in form components

Xperience provides different form components for content types that editors will use to input their data. Other form components may also have additional configuration options.

For example, the Long text data type comes with different text-based form components, such as the Text input, Password, URL, or Rich text editor.

Configuring an editing component for a text field

Form components also come with various configuration options that provide different editing experience. Developers can, for example, configure the Rich text form component as Structured content, Email content, or Contact notes. Developers can also customize their own configuration. The following image shows KBank’s Rich text editor configuration options; the last News page editor configuration is custom.

Additional field configuration options

Find out more about available Admin UI form components and the React input type components in the documentation.

Leverage linked content items

Xperience allows editors to compose their content items by combining data stored in several other content items.

Let’s take a look at the Product content type discussed on the previous page. Highlighted fields store the actual data inputs; the light fields keep references to other content types that hold the values.

Content model diagram

You can see that the Product type contains fields like Product features, Product benefits, or Product image. Sure, you can create two more fields and store values of product benefits and their icons within the Product. At the same time, why would you?

In real life, more than one product will offer the same benefits, such as included internet banking, getting a quick decision, or fast access to funds if we take the KBank demo site example.

KBank demo site example

Storing the information about benefits within the individual product content item restricts access to this data only within the context of this one (and only one) product item itself. If another product allows for fast access to funds, editors will need to duplicate the same wording and decorate with the same icon in another product item. And duplicating the same content often leads to content management nightmares.

The benefits of creating composable content types that store only references:

  • help with content curation,
  • prevent editors from duplicating the same content,
  • improve content management and long-term content curation,
  • lead to quick content composition.

When defining the content model, discuss which types have the potential to be reused - and make sure to create the content types accordingly. To ensure reusability, developers will use the Content item data type with the Content item selector form component.

Developers also specify which content type editors can select when they work with their content. Currently, Xperience doesn’t allow selecting more than one content type through the content item selector.

When an editor selects content items they want to use, rather than copying the values from the original item to the new item, Xperience creates a reference between these records.

And when an editor updates the referenced item, the content changes are automatically promoted to every other item that uses of this content, making content management a breeze. From the developer perspective, querying linked items returns a collection they can process further in their custom code.

Xperience currently doesn’t support creating ordering or limiting the number of items editors can add and manage in the linked items selector field. If the editor teams need to order items, for example, within a group, we recommend using a hierarchy of items ordered in the content tree.

One of the most typical examples of reusable content types is content item assets that users store in the Content hub. See further examples mentioned in this guide in the KBank demo website project.

Store files

Work with managed files

Xperience allows you to store files various file types in Xperience, such as photos, pictures, sound files, videos, package files, presentations, or document files. We call files stored through the Xperience interface managed files. Xperience comes with tools that allow editors to upload the files into the system or add their uploaded files to the rest of their marketing content. To help developers, Xperience contains prebuilt form components for uploading or selecting the files, procedures for storing the files, or optimized methods that developers can call to retrieve the files to the live site.

Xperience doesn’t restrict you to storing only media. You can also store non-media types of files such as spreadsheets, PDF files, and others. Using the Settings application and custom definitions in code, developers ensure that editors can work with different files as specified in the project requirements.

If you have a less experienced team of editors, ask your developers to extend Xperience and customize the application to only allow uploading files of specified types or limited size.

Files stored in Xperience can also be served through a CDN. Xperience natively supports using Azure Blob storage and Amazon S3 file providers. However, developers can also customize Xperience to support other file providers

Xperience comes with two approaches to storing managed files:

Store assets in Content hub

As the Content hub application is the centralized location for managing and distributing marketing content, we recommend storing your media files here.

Editors can store any file types. Out-of-the-box, Xperience supports most common file types. Developers can additionally configure the Content hub application to support different file types or file sizes. Storing files in Content hub also allows editors to restrict access to a specific asset only for authenticated users. 

Asset content type

To store files in Content hub, developers can create a custom content type and prepare fields based on the project requirements of a custom Media or Asset content type.

From Xperience’s perspective, an Asset content type should contain the binary file and additional related information. Xperience comes out of the box with the Asset selector form control that you can use when defining the content type.

For example, KBank’s Asset type consists of the File field that uses the Asset uploader form control and references the binary itself, and additional fields, such as AltText or Description, that marketers can use to categorize or decorate their data.

Content editing interface example

When editors add an image to their content item, they use the Content item selector form component that is scoped against the Asset content type. To display the assets correctly, developers need to retrieve the linked assets. At the same time, the built-in Rich text editor natively supports selecting assets form the Content hub into the text field, and automatically retrieves them from the hub.

Recommendations – Content hub assets

Use Content hub to:

  • Store any type of files.
  • Store additional custom asset properties in a structured format.
  • Require authentication to access an item (content security policy).
  • Reuse stored files on other channels managed by Xperience (future).

When to store files in Media libraries

Media libraries application offers a second way of storing files in Xperience. Despite its name, editors can add files of any type, as in the Content hub, and reuse them in different content types across the website. Developers can use the out-of-the-box Media file selector form component when they define content types that usually contain some media element, such as articles, banners, or videos.

Editors can create a hierarchy of folders within a media library to store their files. They can also adjust some basic properties of the file, such as its title or description.

Media file editing interface

When an editor selects the file they want to display on the live site, they create a reference to the file stored in the media library. Developers can access media library files without querying the database, reducing overhead. This makes media libraries ideal for storing all website files in one central location. The media libraries must be deployed in Azure Blob storage when deploying to the SaaS environment.

Unlike assets stored in the content hub, media files cannot be hidden behind a login. Do not use media libraries for files that are not intended to be public. Media library files are always accessible at their direct URL by their GUID (e.g.,

Using files stored in media libraries isn’t limited to the website’s content types. Developers can prepare mechanisms that allow editors to use:

  • Files from the website to other marketing channels, and share the file’s URL with external users if required.
  • When you need to bulk-upload a large number of files.
  • Media libraries for managing large amounts of files of any types that the business controls.

Recommendations – Media libraries

Use media libraries to:

  • Maintain taxonomy over a large number of files.
  • Store sizeable files (videos).
  • Reuse stored files on other marketing channels outside Xperience.

Based on the size of the editing team and the way the team works, we recommend creating a more granular system of media libraries rather than a massive media library with a complex subfolder structure.

Note on unmanaged files

You can also use unmanaged files in your Xperience application. Unmanaged files refer to all files that content creators do not edit from the Xperience administration or via the platform’s API. Examples include:

  • Static files used for website design, such as images, favicons, fonts, JavaScript, and CSS files, stored in the wwwroot folder.

  • Files stored in the website project outside of media libraries. Such as files required by custom functionality or integration unrelated to Xperience content management .

Create channel-specific content

From marketing perspective, not all content will be distributed across multiple marketing channels. Content like personalized call to action button labels or page headings will likely be specific to only the website channel, and it doesn’t have to exist in the Content hub. Your team will create these items directly inside the channel and keep it there. For this reason, it’s not possible to create channel-specific content like a page with URL directly in the Content hub.

When deciding between reusable and channel specific content, follow a simple rule of thumb:

Is there a possibility that editors will reuse this piece of content on a different channel in the future? Yes – Make it reusable.

Make designing content generic

Though you might want to store design-specific information, like exact color codes or sizes inside the channel-specific content types, we do not recommend this. From content longevity perspective, you want to have your your design information as agnostic to the visual design as possible. When you decide to, for example, redesign your brnad, it’s easier to remap generic class name to new colors than change specific #F05A22 brand color code in hundreds of different places. The following screenshot shows styling options in the KBank demo site.

Styling options

You have learned about the options for storing data in Xperience. In the Design content section, you’ll learn about different approaches to designing and presenting this data in your application.