Approach to meta data modelling

2025/09/08 12:25 PM

Hi all,

We have a K13 site and are currently in the process of estimating a replatforming to XbyK. The K13 site has a number of custom tables that are used for "lists of things" e.g. resource type, job titles, industry list, etc. These lists are pulled into page types into list controls (drop down, radio buttons, etc.) and editors can select from the predefined lists when creating pages. Pretty standard K13 stuff.

What is the recommendation for rebuilding these lists in XbyK? There are no custom tables so I see the options as

  1. Create custom module tables, which are flat, and would function in much the same way as K13 custom tables but it would be more development.
  2. Use the content hub - less development and would support multilingual OOTB. Each "thing" would be a reusable content item and the content types would pull the list of "things" into the Content tab so that editors can use them when creating content.
  3. Secret option #3???

#2 feels like the best option. Are there any reasons to not have this type of "content" in the content hub e.g. performance?

Environment

Tags:
Content hub Content querying Content types Custom modules

Answers

2025/09/08 7:39 PM

Hey David,

Kentico recommends migrating custom tables either as custom module classes (default behavior) or as reusable content items in the Content Hub. So you’re on point here, the Migration tool supports both options.

When deciding where to migrate such data, I usually ask whether it’s more like content or more tied to custom functionality. If it’s functional, I go with a custom module. If it’s content-like, I choose reusable content.

In your case, though, I’d consider using Taxonomies, since resource types, job titles, or industry lists are mainly meant for labeling and organizing content. The Migration tool doesn’t migrate custom tables into taxonomies automatically, so you’d need to set up the taxonomy structure and create a custom migration script to move the data.

2025/09/08 10:31 PM

^ Milan covered everything I would have recommended.

My initial thought was "this could be taxonomies".

If you need a different type of content management UX, then the question "is this data or content" is where I start.

I default to content because it's easy to manage as a marketer (using the combined content selector), easy query as a developer with the content retriever (plus, automatic caching), and often teams would want more and more of the nice content features over time anyway.

  • Content sync

  • Localization (and AIRA translations)

  • Publishing workflows

  • Workspaces

  • Smart folders

  • Usage tracking

If you want to keep this bulk data out of the marketers' day-to-day work in the Content hub, create a new workspace and store it there. This type of content is usually managed by a select group of people so a workspace would let you delegate editing permissions for it very easily.

If instead this really is data, then yes, a custom object type (and a custom application) is the best approach. Custom tables won't be coming to Xperience (at least not supported by Kentico).

These shouldn't take that long to build out - AI agents are pretty good at following the patterns in the docs and building the required parts for you:

  • Application page
  • Listing page
  • Create/edit page

To response this discussion, you have to login first.