Experience Sitecore ! | More than 200 articles about the best DXP by Martin Miles

Experience Sitecore !

More than 200 articles about the best DXP by Martin Miles

Blog content

So, don't miss out! Subscribe to this blog/twitter from the buttons above!

Content Hub One full review: good, bad and ugly

Most of my readers know me as a dedicated Sitecore professional, however, those who are close to me are aware of the variety of my hobbies. Some of them also know me as a Scotch whisky expert and collector. After living for almost 15 years in the UK I got a pretty decent collection of these spirits and learned hundreds of facts from attending dozens of whisky distilleries in Scotland.

Once I got my hands on a new SaaS offering from Sitecore - Content Hub One, I decided to give it a try on a practical example and try its capabilities as I was doing a real application. What would I use for the demo purposes? Something I know much about  - that's how exposing my whisky collection was chosen. Let's go through all the way starting with content modeling, going through actual data and media authoring and publishing, and eventually creating a headless app for content delivery.


First look

Once I got access to Content Hub ONE, I felt curious about what can I do using it. After logging through the portal, I got the ascetic main interface:

It exactly mimics your expected activities here: Content Types is used for Content modeling, Media - is for uploading media assets and Content is for creating content from your types and referencing uploaded media.

Content Hub One comes with handy documentation that helps understand the operations.

Content Modeling

For my purpose, I need to set up two content types - a listing type featuring items from the collection and item types itself to be used on the corresponding pages (marketers also know them as PLP and PDP).

Let's start with a Whisky type which represents the actual item from my collection. You can only choose from these basic field types:

  • Text type can be either short single-line value or multi-line long text up to 50,000 characters
  • Rich text includes markup and can take even more - 200,000 characters. It does not accept raw HTML.
  • Number, Boolean, and Date/Time are obvious and speak for themselves.
  • Reference gives the ability to link other content records to this item, with the unfortunate limit of max 10 items per field
  • Media is similar to the above with the difference that it allows referencing uploaded media items.

Unfortunately, some crucial fields are missing, such as those used for storing Links, URLs, and email addresses.

I ended up with the following structure for a Whisky item type that features as many of various field types as possible:

Next, let's create a Collection type to include a collection of items as well as some descriptive content within Rich text type:

Pay attention to the Archive field. From the home page, I want to distribute a zip archive with all 50 images of my collection, so I included this media field. The challenges of this implementation are described below.


Content Hub ONE users can upload media so that it gets published to Experience Edge CDN. However, its usage is very limited to only images of GIF, JPG, PNG, and WEBP formats.

That is not sufficient for my demo purposes. I also need to upload videos of creative ads for each of my whisky items, as is referenced at Whisky type and I also want to upload a ZIP archive with all the 50 images featuring my entire collection, referenced at Collection type. This is not something extraordinary and is very common for content-powered websites.

So, the question is - can I upload archives and videos? Officially - no, you cannot. However, nothing stops you from renaming your asses to something like video.mp4.jpg or archive.zip.jpg so that it successfully passes upload validation and actually gets uploaded and later published to Edge. With 70Mb limit per media item, it can host pretty much reasonably converted videos, archives, or whatever you may want to put there.

Note: please be aware that since anything else than images isn't officially supported, you may lose access to that content once. Use it at your own risk!

Further below I will show how to build a head application that can consume such content, including "alternative" non-supported media types.


There is the documentation for the developers, a good start at least.


Content Hub One comes with helpful CLI and useful documentation. It has support for docker installation, but when speaking about local installation I personally enjoy support for installing using my favorite Chocolatey package management tool:

choco install Sitecore.ContentHubOne.Cli --source https://nuget.sitecore.com/resources/v2

With CLI you execute commands against the tenants with only one active at the moment. Adding a tenant is easy, but in order to do you must provide the following four parameters:

  • organization-id
  • tenant-id
  • client-id
  • client-secret

Using CLI you can do serialization the same as with XP/XM platforms and see the difference and that is a pretty important feature here. I pulled all my content into a folder using ch-one-cli serialization pull content-item -c pdp command where pdp is my type for whisky items:

The serialized item looks as below:

id: kghzWaTk20i2ZZO3USdEaQ
name: Glenkinchie
    value: 'Glenkinchie '
    type: ShortText
    type: ShortText
    value: 12
    type: Integer
    value: >
      The flagship expression from the Glenkinchie distillery, one of the stalwarts of the Lowlands. A fantastic introduction to the region, Glenkinchie 12 Year Old shows off the characteristic lightness and grassy elements that Lowland whiskies are known for, with nods to cooked fruit and Sauternes wine along the way. A brilliant single malt to enjoy as an aperitif on a warm evening.
    type: LongText
    - >-
        "type": "Link",
        "relatedType": "Media",
        "id": "lMMd0sL2mE6MkWxFPWiJqg",
        "uri": "http://content-api-weu.sitecorecloud.io/api/content/v1/media/lMMd0sL2mE6MkWxFPWiJqg"
    type: Media
    - >-
        "type": "Link",
        "relatedType": "Media",
        "id": "Vo5NteSyGUml53YH67qMTA",
        "uri": "http://content-api-weu.sitecorecloud.io/api/content/v1/media/Vo5NteSyGUml53YH67qMTA"
    type: Media
After modifying it locally and saving the changes, it is possible to validate and promote these changes back to Content Hub ONE CMS. With that in mind, you can automate all the things about for your CI/CD pipelines using PowerShell, for example. I would also recommend watching this walkthrough video to familiarize yourself with Content Hub ONE CLI in action.


There is a client SDK available with the support of two languages: JavaScript and C#. For the sake of simplicity and speed, I decided to use C# SDK for my ASP.NET head application. At a first glance, SDK looked decent and promising:

And quite easy to deal with:

var content = await _client.ContentItems.GetAsync();

var collection = content.Data
    .FirstOrDefault(i => i.System.ContentType.Id == "collection");

var whiskies = content.Data
    .Where(i => i.System.ContentType.Id == "pdp")
However, it has one significant drawback: the only way to get media content for use in a head application is via Experience Edge & GraphQL. After spending a few hours troubleshooting and doing various attempts I came to this conclusion. Unfortunately, I did not find anything about that if the documentation. In any case with GraphQL querying Edge my client code looks nicer and more pretty, with fewer queries and fewer dependencies. The one and only dependency I got for this is a GraphQL.Client library. The additional thing to add for querying Edge is setting X-GQL-Token with a value, you obtain from the Settings menu.

The advantage of GraphQL is that you can query against the endpoints specifying quite complex structures of what you want to get back as a single response and receive only that without any unwanted overhead. I ended up having two queries:

For the whole collection:

  collection(id: ""zTa0ARbEZ06uIGNABSCIvw"") {
    archive {
        results {
        ... on Pdp {
        picture {
            results {

And for specific whisky record item requested from a PDP page:

  pdp(id: $id) {
    picture {
        results {
    video {
        results {

The last query results get easily retrieved in the code as:

var response = await Client.SendQueryAsync<Data>(request);
var whiskyItem = response.Data.pdp;


Some challenges occur at the front-end part of the head application. 

When dealing with Rich text fields you have to come up with building your own logic (my inline oversimplified example, lines 9-50) for rendering HTML output from a JSON structure you got for that field. The good news is that .NET gets it nicely deserialized so that you can at least iterate through this markup:

Sitecore provided an extremely helpful GraphQL IDE tool for us to test and craft queries, so below is how the same Rich text filed value looks in a JSON format:

You may end up wrapping all clumsy business logic for rendering Rich text fields into a single Html Helper producing HTML output for the entire Rich text field, which may accept several customization parameters. I did not do that as it is labor-heavy, but for the sake of example, produced such a helper for Long Text field type:

public static class TextHelper
    public static IHtmlContent ToParagraphs(this IHtmlHelper htmlHelper, string text)
        var modifiedText = text.Replace("\n", "<br>");
        var p = new TagBuilder("p");
        return p;

which can be called from a view as:


Supporting ZIP downloads

On the home page, there is a download link sitting within Rich text content. This link references a controller action that returns zip archive with the correct mime types.

public async Task<IActionResult> Download()
    // that method id overkill, ideally
    var collection = await _graphQl.GetCollection();

    if (collection.Archive.Results.Any())
        var url = collection.Archive.Results[0].FileUrl;
        var name = collection.Archive.Results[0].Name;
        name = Path.GetFileNameWithoutExtension(name);

        // gets actual bytes from ZIP binary stored as CH1 media
        var binaryData = await Download(url);
        if (binaryData != null)
            // Set the correct MIME type for a zip file
            Response.Headers.Add("Content-Disposition", $"attachment; filename={name}");
            Response.ContentType = "application/zip";

            // Return the binary data as a FileContentResult
            return File(binaryData, "application/zip");

    return StatusCode(404);

Supporting video

For the sake of a demo, I simply embedded a video player to a page and referenced the URL of published media from CDN:

<video width="100%" style="margin-top: 20px;" controls>
    <source src="@Model.Video.Results[0].FileUrl" type="video/mp4">
    Your browser does not support the video tag.

Bringing it all together

I built and deployed the demo at https://whisky.martinmiles.net. You can also find the source code of the resulting .NET 7 head application project at this GitHub link.

Now, run it in a browser. All the content seen on a page is editable from Content Hub ONE, as modeled and submitted earlier. Here's what it looks like:


Content Hub ONE developers did a great job in the shortest time and there should not be any questions to them. However, from my point of view, there is a big number of both minor and major issues that prevent using this platform in its current stage for commercial usage. Let's take a look at them.

1. Lack of official support for media items other than four types of images is a big blocker. Especially given that there is no technical barrier to doing that in principle. Hopefully, that gets sorted with time.

2. Many times while working with CH1 I got phantom errors, without understanding the cause. For example, I want to upload media but got Cannot read properties of undefined (reading 'error') in return. Later I realized that was caused by session expiration, which for some reason is not handled well in the cases. What is more frustrating - I got these session issues even after just navigating the site, as if navigation did not reset the session expiration timer. But since that is SaaS product - it's only my guesses without having access to internals.

3. Another issue experienced today was CH1 got down with UI showing me a Failed to fetch error. That also occurred with my cloud-deployed head app which also failed to fetch content from CH1. Unannounced/planned maintenance?

4. Not being able to reference more than 10 other records seriously limits platform usage. With my specific example, I had around 50 items of whisky to be exposed through this app but was able to include only max 10 of them. What is worse - there are no error messages around it or UI informing me about the limitation in any other way.

5. When playing around with the existing type I cannot change the field type, and that limitation is understood. The obvious solution would be deleting that field instead and regrating it with the same name but another type (let's assume there's no content to be affected). Wrong, that's not possible and eds with Failed entity definition saving with name: 'HC.C.collection' error. You can only recreate the field with a new name, not the same one you've just deleted. If you got lots of queries in your client code - need to locate them and update them correspondingly.

6. Not enough field types. For example, URL could be simply placed into a small text field, but without proper validation, editors may end up having broken links if they put a faulty URL value on a page.

There is some of UI/UX to be improved

1. Content Hub One demands more clicks for content modeling creation compared to let's say XP. For example, if you publish a content item, related media does not get published automatically. You need manually click through media, locate it and publish explicitly. On large volume of content that annoys and adds unwanted labor.

2. To help with the above, why not add a "Publish" menu item into the context menu upon an uploaded item in a Draft state? That eliminates the unwanted step of clicking into the item for publishing.

3. On the big monitors the name of a record is mislocated in the top left corner making it unobvious to edit it, given that, it is not located with a form field, so not immediately obvious that is editable. That is especially important for records that are not possible to rename after creation. Bringing the name close to the other fields would definitely help!

4. Lack of drag&drop. It would be much easier to upload media by simply dragging the files onto a media listbox, or any other reasonable control.

5. Speaking about media, UI does not support selecting multiple files for an upload. Users have to click one after another.

6. Need better UI around grouping and managing assets. Currently, there are facets but need something more than that, maybe the ability to group records into folders. I don't have a desired view on that, but definitely see the need for such a feature, as my ultra-simple demo case already requires navigational effort.


I don't want to end up with the criticism only leaving a negative impression about this product: there are plenty of positives as well. I would only mention just a few: decent SDKs, attention to the details where the feature is actually implemented (like the order of referenced items follows up the order you select them), nice idea of a modern asynchronous UI that can notify you about when the resource gets published to Edge (just need to sort out the session expiration issues).

Content Hub One is definitely in the early stages of its career. I would wish the development team and product managers to eventually overcome the "child sickness" stage of the product and deliver us a lightweight but reasonably powerful headless CMS that will speed up content modeling and content delivery experience. The foot is already in the door, so the team needs to push on it!

Merry Christmas and happy New Year!

Every year I create a special Christmas postcard to congratulate my readers on a new oncoming year, full of changes and opportunities. Wish you all the best in 2022!

My artwork for the past years (click the label to expand)







The ultimate guide to Sitecore XM Cloud

If you ask anyone in the Sitecore community what was the biggest hype of 2022 – there wouldn’t be any other opinion than mentioning XM Cloud. Let’s take a look at this latest and shiny SaaS offering!


Overview, Architecture, Features


Sitecore XM Cloud is a cloud-based platform that provides tools and features for managing and optimizing digital customer experiences. The platform is a headless SaaS solution initially designed to resolve certain points of pain XP platform previously suffered from, including

  • Platform upgrades: one of the time-consuming and uncertain activities that eat out a significant budget, but on their own bring very little of new features. I have written a decent series of blog posts exclusively devoted to the Sitecore platform upgrades and the accompanying complexities. With the SaaS model, you get upgrades automatically done for you by Sitecore.
  • Infrastructure management and maintenance, security maintenance, taking care of scalability: all that was previously done by the end clients or partners now is fully managed by Sitecore itself.
  • A bottleneck of Sitecore developers: lack of availability of developers with specific knowledge of Sitecore internals may encounter a staffing bottleneck when building and maintaining Sitecore-based applications, including the complexity of the platform, limited documentation, dependence on the Sitecore support team, and limited resources. Since most of that is now provided by the vendor, development shifts mainly to the “head” and requires generic frontend skills that are much easier to come by.
  • Platform architectural bottleneck: in addition to all the above, previously scaling up your CD servers in a non-headless environment was quite a bottleneck and came at a cost compared to XM Cloud which does not have CDs at all, but only serves content via highly available Edge APIs endpoints.

That results in a drastically improved development process, velocity, and reliability; not to mention saved budgets. Clients can mostly focus on building the sites for visitors, where the platform itself gets care from the vendor.


Before talking about licensing, it is important to understand how this SaaS offering is structured.

XM Cloud hosting platform includes the concepts of organizations, projects, and environments. An organization is the equivalent of an XM Cloud subscription. To initially access the XM Cloud portal, you must be a member of an “Organization” admin account at Sitecore. Once you have access to this account, you can manage your users, give them the required access or even set them as admins, create projects, set up environments for those projects, and promote your code through these environments. In old XP terminology, each environment is a Sitecore instance.

There are three environments per project: one production and two non-prod – typically for development, staging, testing, or other purposes. With the XM Cloud portal, you can easily manage and access all of your Sitecore instances in the cloud.

Coming back to the licensing model, it is similar to a subscription license from Sitecore platforms and its cost model was simplified very much to be based on traffic and consumption.

Each XM Cloud license includes a certain number of projects and environments, and you can use these to manage your different Sitecore instances. Depending on your specific requirements, you may be able to use different projects to handle different instances. You can use environments to set up and configure your development, staging, testing, and production environments, as well as any other environments you may need. If you have any questions about how to best use projects and environments, or if you have any other licensing questions, it is recommended that you speak with your Account Manager, who will be able to provide more information and guidance to meet your specific needs.

Interestingly, in order to run local docker containers with XM Cloud, one requires to have a valid Sitecore license. I cannot say if your existing partner’s license file will work with local containers development, as being a Sitecore MVP I was given a universal Sitecore license file which worked well. For building and deploying a source code with a built-in Deploy App you don’t need to provide a license file – it is assumed from your organization (subscription).

xm cloud license


In very simplified terms, the architecture could be explained by the below diagram provided by Sitecore:

XM Cloud architecture

Not all the internals of the architecture are mentioned above (ie. ACR, Kubernetes, etc. are missed out), but should you really care about anything within the dashed area? All that is Sitecore-managed and developers typically focus on the development of the front-end website (also known as a “head”) which is most often built with Next.js. Of course, other frameworks also would work with XM Cloud, however, there’s lots of plumbing to be done that Next provides out-of-box.

One of the most important features of XM Cloud is Webhook Framework. It is built into XM Cloud in the same as is for 10.3 platforms. In a composable world of decoupled SaaS products webhooks are used to notify external services about changes in XM Cloud, for example, to validate and even cancel Workflow state transitions.

For example, in the old good XP platform, we used events to notify that publishing to CD has been completed. One of the possible scenarios was using Core database to pass the remote events as that was an architectural feature of a monolith platform. In a composable world that cannot be the case, as systems cannot share resources in that way and can only communicate through APIs. You don’t have CDs and publish to Edge which reasonably also has its own webhooks. You could also utilize webhooks on git repository or at Vercel side for example.

With some obvious architectural limitations, it is possible to customize XM Cloud in a similar way as we did it with XP by applying patches, but there is an expectation is that developers would customize less and less with time and platform growth. From the functionality point of view, these customizations would focus on data and synchronization rather than patching system features.

Speaking about the drawbacks of XM Cloud I could state single region geolocation, which you must specify initially.

Cloud Portal

It is a visual dashboard of your Organization. Here you can get all your tools in the same place, based on what you have in your subscription. In addition – there are shortcuts to Documentation and you can access Support from the Portal as well.

cloud portal

You can create projects and environments right from this portal. Choose between a starter template or setting up your GitHub repository and if the latter has been chosen – once you grant access to XM Cloud Deploy App to your account and choose the desired repository – it will perform the deployment in the background.

You choose a specific git branch for the desired environment (for example – main branch deploys to the production environment, while develop branch – is to testing) and can also enable auto-deploy upon each commit to a chosen branch. There is nothing else to set up or configure on top of the above, like CI/CD pipelines – Deploy App already knows what to do.

Is GitHub the only way to provide source code for build and deployment? The answer is both yes and no: from GUI it indeed currently only supports GitHub, with later plans to add support for other popular version control hosting providers, such as Azure DevOps, GitLab, Bitbucket, etc. But from CLI one can have more configuring options.

And not just that – almost everything you can do on the portal with GUI you can do remotely with CLI, for example. However, many of the Cloud Portal tools are not available for local development: Pages, Components, Explorer, Deploy App, and Dashboard itself all run exclusively in the cloud and are not available to run locally.

So, how would I develop it at my local rendering host and test it then with Pages or Experience Editor running in the cloud? Currently, there’s a workaround to configure tunneling for the local Rendering Host with a reverse proxy like ngrok or localtunnel, so that your local rendering host server becomes available outside.

If using default GitHub is not an option or you want to customize the automation and/or set your own CI/CD pipeline, there’s another feature of Cloud Portal named Authentication Clients available – an access token generator for XM Cloud.

This is how the documentation describes it:

“When you generate an authentication client, the client creates credentials that include a client ID and a client secret. You can use the credentials to request a JSON Web Token for your CM instance or to request a JWT for Experience Edge XM.”

So, that is an effective tool for creating tokens for approving custom tools for the automation and/or setting your own CI/CD pipeline.

The third tab named Status provides a basic but helpful overview of a deployment process.

I would recommend reading through the official Cloud Portal documentation.


With the XP platform, we used to have an Identity Server however the one is no longer useful in a genuine composable world. Sitecore had to re-think the authentication approach and implemented a new Unified Identity system so that it offers SSO across all applications of the Composable DXP family.


How XM Cloud integrates with Content Hub DAM and CMP out-of-box and reference to the CMP/DAM connector now in the base image.

Sitecore Experience Edge

Experience Edge for XM comes out of the box with XM Cloud and is the default destination for publishing content. It is a content delivery service that provides scalable, globally replicated access to Sitecore Experience Platform items, layout, and media through an API. It uses CDN networks to distribute published content across the globe, ensuring a fast experience at scale.

The Edge for XM connector is required to publish the content from your pages and components in Sitecore XM Cloud to the highly scalable Sitecore Experience Edge delivery platform. It is also included.

GraphQL schema used by Experience Edge in XM Cloud is the same as used for 10.3 platforms (with a minor difference in temporal query complexity limits). However, XM Cloud schema is different from those used in Content Hub and Content Hub One as they implement different underlying data structures.

Speaking about security, previously on XP when we dealt with “protected” pages, security data went along with published content to CD servers, where Sitecore platform implemented it in the correct way. With XM Cloud we don’t have a CD server any longer, we publish to Edge Content gets published to Edge regardless of that permissions. Of course, it is not immediately available to the outer world – without a valid API key, it is not possible to access it. But instead of a fully compliant Sitecore CD server we now got a “head” which is a totally detached piece of technology. Having API Key, head may, or may not respect the security rules – Edge will give it out anyway. So, you should extra care and test these things while developing head application on your rendering host.

Familiar XP tools that have gone out of XM Cloud

Since we do not have xDB and xConnect within XM Cloud architecture, many features from XP did not find their way to the new composable world. We have to say goodbye to:

  • XDB
  • EXM
  • Identity Server
  • FXM
  • Path Analyzer

In addition, because of the exclusively headless architecture of XM Cloud, not having CD servers, and operating through Edge these features also went off this SaaS platform:

  • MVC renderings, including classical SXA
  • Publishing Service
  • Sitecore Forms
  • Custom Search Indexes
  • Universal Tracker

Sitecore Forms have gone simply because there is nowhere to submit the data back to. It is expected that Sitecore comes up with a sort of SaaS forms component to be used with a composable family of products. Meanwhile, you can consider using something like Jotforms, Marketo, Hubspot Forms, etc.

As for implementing search functionality – despite Solr still being a part of this platform for supporting XM needs (same as does it for XP), however, without having CD servers there is no more reason to have custom search indexes. Implementing a search feature for your website now requires a composable search component. I will talk through it in more detail below.

Sitecore platform features that still remain

  • Media Library exists and functions exactly the same as with XP
  • The above could be said about Workbox and workflows
  • Content Editor and Experience Editor remain untouched
  • We still have the luxury of poking the system internals with Sitecore PowerShell Extensions, this component is built-in since that is a requirement for the same built-in SXA Headless
  • Many other less important features stay

As said above, custom search indexes are no longer available and one has to select from a choice of composable options: Sitecore Search, Coveo, or Algolia – those first come into my mind. All these products are platform agnostic and will integrate seamlessly with any site regardless of underlying CMS or web engine.

There might be several approaches for implementing external search with XM Cloud:

  • Using search-based queries from Experience Edge directly. The development team can write searches against our Experience Edge endpoints and call from their application.
  • Using a crawling search engine. Sitecore Search has been released and got already proven on several implementations including sitecore.com website. Currently, it indexes against rendered HTML markup, however, Edge support should come up with future releases.
  • There’s still an option of setting up and configuring your own external Solr solution to send content to it. Also, SearchStax Studio for XM Cloud could be another alternative option. 

Headless SXA

The headless part of SXA is provided with Sitecore XM Cloud, a cloud-based CMS platform. It allows developers to build and deploy headless websites using XM Cloud, taking advantage of all the known existing SXA features, such as Page Layout, Partial Layout and especially Rendering Variants.

In addition, new concepts were introduced: Page Branches, and standard values for layout on a per-website basis.

What I found really great was the out-of-box implementation of SEO-related things, such as:

  • sitemaps
  • robots.txt
  • redirect items
  • redirect maps
  • errors (404 and 500)

This version of SXA supports Next.js as a first-class citizen and therefore has a revised list of components, leaving only those most basic to work (here they are all). With years of SXA practices, it became a default way of doing things to clone components and add rendering variants to existing ones. Assuming the same, Rendering Variants remain with us in a headless world, however, Scriban is no longer there, replaced with Next.js. Here is an example of how Rendering Variants are defined within a single promo.tsx file with Next.js implementation – there are two of them named Default and WithText. It’s really simple and similar to Scriban.

When you set up an empty site you have default SXA Headless components (at the components tab). Drag and drop works, and also works dragging components along the screen to the position. The right-hand-side section features component properties, including styling.

component tab

There is a content tab that shows item properties similar to what it was before in Content Editor.

CLI and Serialization

Similar to the XP platform, CLI operates through built-in Sitecore Management Services in order to support Sitecore CLI.

Almost everything that can be done through the Cloud portal can be also done through the Sitecore CLI. The latest version of CLI allows the creation of Projects, New Environments and Deployments, and much more.

Sitecore CLI allows you to take existing serialized content and move it directly into XM Cloud. Since serialization is done in YAML format, it stays the same as with XP and also is compatible with Unicorn, therefore correctly formatted content is easily portable to XM Cloud. I want to emphasize that it is only about serialized content, Unicorn itself is an XP module and cannot be installed on XM Coud.

New Tools and Interfaces

Old good Content Editor and Experience Editor still remain with us and that’s good news for those who habitually stick to the interfaces. they used to. Nevertheless, this blog post will familiarize you with the totally new apps and interfaces coming with XM Cloud.


This application opens by default. It shows up all of the websites available in the system with the predictive typing search bar to filter them out. Clicking any of the sites opens them up in a Pages app, as expected.

What is more interesting is the ability to create websites directly from this interface by clicking the “Create website” button.

create website


If you played around Horizon in the latest versions of XP such as 10.2, you will immediately recognize this user interface. Pages are built on the foundation of Horizon:

Pages application

The Pages application has 5 views which you select from the left navigation stripe:

  • Pages
  • Components
  • Content
  • Personalize
  • Analyze

I personally find it a little confusing, that some views have the same names and apps. For example, by clicking the Components view of the above Pages app from the left bar navigation, you will see a component selector which you can drag and drop to the editable page. However, this is totally different from the Components application which is a turbocharged tool for creating components to be used on a page, which you later choose by the mentioned component selector of Pages application.

I want to highlight that Pages was done with attention to minor details. It has very pleasant animation effects for many transitions, leaving you with a premium experience feelings. There is no “Save” button anywhere as Pages application autosaves your changes.

It also has support for multiple websites selected from a dropdown. Preview, Devices Experience, Navigation Tree – all these features are located at the same interface you would expect in order to have a productive editing experience.


The tool is still in its early stages, but it has a lot of potentials. Its purpose is to enable content creators and marketers to create components without the need for a developer to start from scratch.

There are lots of styling options to specify custom types, and custom fonts, at least it looks advanced.

Here we create the component and publish it, so that component becomes available in the component library of the Pages app. The intention is for us to be able to put components together and create them together from basic page elements, images, links, and so forth. Starting with a grid, then you simply start adding columns, set alignment, and apply other UI-related things.

But what is the most impressive feature of Components app is – we not only create and customize individual components similar to the way we do it in SXA, but now we create entire components completely from scratch, we can style them and can hydrate them with data from an external data source. By saying external I mean really external: one of many 3rd party content providers and headless CMSs, like Content Hub One, Contentful, Kontent.ai, etc., and all that with zero code!

All you need to do is to provide an API endpoint and use a mouse to select what fields from the source you want to map. For those who are behind a tough firewall or strict corporate policies, there is an option to directly paste in a sample JSON snippet to map against it. They don’t ever have to hit the live API when creating a datasource.

What is even more mind-breaking is that you can feed the same single component from various external systems at the same time. Image a Promo Block component that you can easily drag and drop to a page that consists of:

  • Heading title that sits natively at Sitecore XM Cloud
  • Image taken from Content Hub DAM
  • Localized promo content taken from Contentful CMS
  • Call to action button that is wired up to CDP

In my opinion, that is a superpower of XM Cloud editing capabilities! I very much recommend watching this short video demonstrating the whole power of the new Components app.


How the data is updated and invalidated with Components? It seems that the data is pulled in at the moment when the connection is established, and not get refreshed at the moment of publication.


A cut version of Sitecore Personalize comes built into Pages interface of XM Cloud to allow for basic view event personalization. Therefore there isn’t a one-to-one match of old XP rulesets to the new ones, so a deeper analysis and re-evaluation of your personalization strategy is needed.

With XM Cloud there’s a new way of doing personalization coming out of the box: we have a limited set of rules available to us and those are primarily rules based on the current session, such as day of the week, a visitor’s country, to an operating system of visitor’s current device. However, there’s no way you can manage the built-in Personalize tenant directly from the XM Cloud interface.

Checking carefully, you can still find some rules based on historical data: an example of a history-based rule is the number of page views a visitor has visited pages within the past (max) 30 days. Of course, once you enable full Sitecore Personalize a set of tools will expand the functionality to a wider range of options.

Unlike XP where we would personalize each component individually, in XM cloud we create page variants to achieve that so that we can define the audience that will be exposed to that page variant.

Configuring the audience, you see the default set of rules, I counted 14:

  • Point of sale: The visit is to point(s) of sale
  • Region: The visitor is in region(s) during the current visit
  • Country: The visitor is in country(s) during the current visit
  • Visit day of the month: The visit is on a day of the month that compares to number based on your organization’s time zone
  • Day of the week: The visit is on a day(s) of the week, based on your organization’s time zone
  • Month of visit: The visit is in month(s), based on your organization’s time zone
  • First referrer: The visitor comes from a URL that compares to referrer in the current visit
  • UTM value: The visit includes a UTM type that compares to UTM value
  • Operating system: The visitor is using operating system(s) during the current visit
  • Device: The visitor is using a device type(s) device during the current visit
  • Number of page views: The visitor has visited page within the past x days and the total number of page views compares to a number of views
  • First page: The visit has started on a page that compares to page during the current visit
  • Page view: The visitor has visited page name(s) during the current visit
  • New or returning visitor: The visitor is a specific type to your site

After specifying the audience, you then process customizing components for that page variant.

That is implemented in a very similar manner as it was back in the XP: specify the data source item with the desired content, choose a different component to replace the default one, or simply choose to hide the component as another option.


The bigger question comes about how personalization works with Edge, without having CD servers previously responsible for executing personalization. It is important to understand that the personalization logic is now happening at the Vercel/Next.js middleware level.

A middleware package intercept browser request at Vercel in order to do audience matching with Personalize, and then serves the relevant content from the Edge, for example by substituting personalized Edge content from one to another. The above approach does not imply any performance penalties at all since all the parts of this chain are super-fast at CDN/Jamstack level at Vercel and also because the content is already cached at Experience Edge. I would recommend spending some time reading through more details about the built-in personalization in XM Cloud by this link.


Another excellent embedded tool powered by Boxever page-level analytics: pages built-in with Pages have embedded tracking tag therefore analytics become auto-available. Just out of the box it will empower you to see:

  • the browsers the operating system
  • the source where they came from
  • the pages: first page, entry page, top pages
  • visited top countries
  • by source visits
  • by time of the day

Analytics presents data with a heat map for the time of the day with most traffic shown by darker rectangles.


Similar to the previous example of Personalize, this analytics system is now built on top of the Sitecore CDP. Previously all the analytics was taken out from Sitecore XDB, and without having that in SaaS cloud offerings the only option for providing built-in analytics and personalization was to rely on CDP and Personalize in some way.


In addition to Pages you can use Explorer for editing content. I think the main idea of this interface was to give editors the ability to switch rapidly between visual and filled editing interfaces.

Explorer presents you the content with some similarity to Horizon performing on XP: kind of a Content Editor with navigation and the ability to publish and edit items at the fields level. You can do many expected content operations here like modify, copy, upload download media assets, etc.

Interestingly that Sitecore decided to walk away from a tree-based style of presenting content structure to a drill-into way of navigation. It definitely makes things clear, and when we need to take a look at the entire structure of the content tree – there is still old good Content Editor to our help.


Site Identifier

This is an interface to add a tracker to your websites if they are missing so that they become trackable with Analyze section of Pages app.

site identifier

That was an overview of the most important new applications and interfaces coming with XM Cloud. The part of this post will take you through the development experience with XM Cloud.

Development with XM Cloud

In the final post of the XM Cloud series, we’ll talk about the development process with XM Cloud and its nuances. I assume you’re either familiar with the traditional way of Sitecore development or at least get some basic understanding of the process.

In order to identify the difference in the development, let’s quickly recap architectural features of XM Cloud that affect:

  • there are no more Content Delivery (CD) servers available
  • therefore content gets published to Sitecore Edge
  • that, in turn, enforces headless development only

Sitecore Next.js SDK

That means we now have a “head” web application running on a Rendering Host. That would be most likely built with Sitecore Next.js SDK – using Next.js on top of React with TypeScript running on a Node-powered server. Next.js is a framework created by Vercel that is built on top of the React library, designed to help developers build production-ready applications with little need for configuration and boilerplate code.

Of course, as a natively headless platform Sitecore allows using any other framework or technology, like Vue, Angular, or .NET Renderings, however, if React is your choice then Next.js SDK will offer you lots of features available out of the box, including

  • Powerful routing mechanism
  • Layout Service fetching and mapping
  • Placeholder Resolver
  • Multi-language support
  • Field Helper components
  • Components Factory
  • Experience Editor support
  • Sitecore Analytics support

I would recommend going deeply through the relevant documentation, as it covers it all in the detail.

A headless architecture consists of a back end with a layer of services and APIs and a front-end/client/user-facing application. The front-end application, or presentation layer, retrieves data from the CMS using API endpoints and uses that data to populate or hydrate the markup it generates.

Without having CD servers any longer, there is no place to execute HTTP request pipeline extensions. Experience Edge provides just raw published data in a headless way, there is no place to apply any logic. But what if you need to modify a request, for example?

In that case, all that logic gets moved to a “head” application, since changes will need to be made in the hosting environment for the client application.

If the Next.js application is hosted on Vercel, a Vercel Serverless Function can be set up to process incoming HTTP requests and generate a response. For Cloudflare Pages, one can choose Cloudflare Worker for the same purpose, and so on.

Similarly, any other integrations or personalization previously taken place on a CD server should be refactored to work with the “head” application at the Rendering Host. It is recommended to use out-of-process API-based integration as much as possible to maintain loose coupling.

Development Modes

There are two approaches for developers to interact with XM Cloud and implement customer requirements: Edge Mode and Fully Local.

With Edge Mode, you developed a classical JavaScript-based rendering app on a local node server.  This app connects to which will connect to the GraphQL endpoint of the Experience Edge which XM Cloud publishes to. This option does not require a license, as Edge relates to your Cloud Subscription which is aware of your license. Therefore you can scale and outsource the development as much as you desire. You can also develop on Mac or Linux, as soon as the OS can run a Node server.

Fully Local development requires containers running on a Windows-based environment and you need to have a valid license file to run it. If running on a client version of Windows (say, 10 or 11) make sure to reference 1809-based images in your .env file.


Once you run it, you may see a list of containers – it is pretty similar to what you can find with the classical XM platform:

xm cloud containers

There is a Solr container used for internal purposes, a container with a SQL server, and init containers for both of them. The main container is called CM, but please be aware (mainly for patching purposes) that the role name is not CM any longer but is XMCloud instead – here’s its definition:

<add key="role:define" value="XMCloud" />

Another important container here is Traefik – the one that accepts and distributes external traffic. One of the most frequent errors occurring while trying to set up local containers is that developers often already have a running web server (for example IIS) that occupies port 80, preventing Traefik running in a container from exposing its own port 80, so that it errors out.

The rest of the containers are providing rendering hosts with “head” applications.

The principal difference of local container development is that instead of using Edge from XM CLoud, your rendering host will connect to the GraphQL endpoint of the CM instance which features the same API as cloud-based Experience Edge (if you’re using Headless SXA then Edge endpoint is configured in the site settings item).

What can a developer control?

You can apply config patches for configuring CM instance, the same as you did before with XP (here's an example). There’s also a guide on deploying customizations to the XM Cloud environment.

That means it is possible to turn things on and off, like overriding pipeline processors. Of course, there is no longer request manipulation with XM Cloud as request processing shifts to the rendering host while httpRequestBegin and httpRequestEnd pipelines relate only to the CM instance itself. Nevertheless, there are lots of other familiar pipelines to deal with.

For your custom code Sitecore NuGet Feed will support relevant packages. All the packages follow up the name pattern starting with Sitecore.XMCloud.* so that one cannot mess them up with the packages for XP/XM platforms. For example, the top-level package is called Sitecore.XMCloud.Platform. Versioning of these packages follows up SemVer version of XMCloud.

Sitecore has an expectation that developers customize it less and less with time, with most of the customization happening around data synchronization rather than the altering system itself.

One of the good news is that you still have the PowerShell Extensions, but that is disabled by default. Enabling it requires setting SITECORE_SPE_ELEVATION environment variable to either Confirm or Allow with new deployment to take effect. Once complete – you get full power, including direct database access. I recorded a short video showing how to enable SPE for your XM Cloud environment, if you also need SPE remoting - read this post for additional instructions.

Sitecore Connect for Content Hub: CMP or DAM connector provided by XM Cloud, is also included in the base container image. There is a promise of adding connectors to other popular systems and DXPs with time.

Unfortunately, installing familiar modules is no longer available in the easy way of package installation we used to.

Build configuration

There is a new important configuration file with XM Cloud – xmcloud.build.json. It configures build targets, editing hosts, XDT transforms, if any, serialization modules to deploy to the XM instance for that environment, etc. Its structure looks as below:

  "deployItems": {
    "modules": []
  "buildTargets": [],
  "renderingHosts": {
    "<key>": <value>
  "transforms": [],
  "postActions": {
    "actions": {
      "<key>": <value>

For example, the default build pipeline of XM Cloud is configured to look at a single *.sln file at the root of your repository to process, but with xmcloud.build.json a developer can override this behavior and specify what exactly to build.

Read more about configuring build configuration with XM Cloud.

Sitecore CLI

With Sitecore XP most of you likely used CLI for serialization purposes, with some rare developers experimenting with itemres plugin for creating items as resources from serialization modules. With XM Cloud Sitecore CLI becomes much more useful – lots of management could (and should) be done using it, like creating the projects and environments, performing initial deployments using CLI, etc.

In order to install it you must have .NET 6 already installed on your machine. The tool consists of two parts – Sitecore Management Services running on CM and the command line tool itself. Management Services comes already preinstalled for XM Cloud (in both development container and cloud instance), so it only comes to installing CLI from the project folder:

dotnet nuget add source -n Sitecore https://sitecore.myget.org/F/sc-packages/api/v3/index.json
dotnet tool install Sitecore.CLI

Here’s an example of using CLI to list projects running against my XM Cloud organization (subscription).

CLI shows list of projects

In the XM Cloud terminology, a project is a set of environments. Each environment is in fact its own XM Cloud CM instance. Therefore, we can list a set of its environments and can take actions towards each individual environment, let’s say publish its content to Experience edge:

dotnet sitecore publish --pt Edge -n <environment-name>

Old good serialization also works well with CLI in order to synchronize items between remote and local XM Cloud instances:

dotnet sitecore serialization pull -n development
dotnet sitecore serialization push -n development

Similarly to 10.x platforms, you may benefit from a Sitecore for Visual Studio if you prefer using GUI for Sitecore Content Serialization. It is not free to use and requires purchasing a TDS license (notably, TDS itself does not support XM Cloud).

One of its greatest features in my opinion is Sitecore Module Explorer for you you to navigate, create and modify Sitecore Content Serialization configuration files as items in a tree structure.

Head Application

Configuring front-end applications mainly comes to these 3 settings:

  • JSS_APP_NAME – the name of a site
  • GRAPH_QL_ENDPOINT should be pointing to Edge GraphQL
  • SITECORE_API_KEY for Edge Token, typically found under /sitecore/system/Settings/Services/API Keys

I would recommend watching this video for the front-end developer setup for XM Cloud.

The really impressive productivity feature is running npm run start:connected where you set up a watch mode against the source code so that changes get immediately updated in the browser.

You can also configure an external editing host for XM Cloud instances so that you could also benefit from editing experiences in Pages.

Edge and GraphQL

There is a common misunderstanding about content published to Experience Edge becoming unprotected. It comes from the official documentation, saying: “Experience Edge for XM does not enforce security constraints on Sitecore content. You must apply publishing restrictions to avoid publishing content that you do not want to be publicly accessible“. In fact, publishing to Edge is not equal to making content publically exposed – no one can access it without providing a valid Edge Token you typically configure as SITECORE_API_KEY parameter for your environment. API Key should never be shared publicly – each time you need to pull the data out of Edge you should delegate that task to your head application in order to obscure API Keys rather than making such calls directly from JavaScript code running in the client’s browser, thus exposing your secrets.

Previously with XP/XM it was possible to extend the GraphQL Preview endpoint for additional features like comparison for integers and dates, coordinates, multifield searches, faceting, etc. It is worth mentioning that now you cannot perform any changes around GraphQL endpoints via pipelines with XM Cloud, because it uses Edge. You can still do the following operators in addition to searching fields by a value: compare with EQ / NEQ, CONTAINS / NCONTAINS, order by field names both ways, do pagination, logical AND, and OR.

You can read more about Edge Schema at this link. Also, it is worth mentioning that Edge has its own webhooks. This can be helpful for notifying a caller when publishing is complete.

Use New-EdgeToken.ps1 script to create one for any desired environment. Upon completion, this script opens up GraphQL IDE automatically as well as returns X-GQL-Token for you to use with IDE straight away.

Note that you can use the GraphQL IDE only if you have installed Experience Edge. However, Edge tenant and edge connecter are created automatically upon the creation of an environment with XM Cloud.

Another thing to keep in mind is that despite you're empowered to use Media Library, there's a GraphQL limitation of 50Mb per resource. For larger files (likely videos), consider using DAMs, given they typically allow wider management options.

XM Cloud Play! Summit Demo

This is an exceptional gift from Sitecore Demo Team to us! It allows you to experiment working with XM Cloud and its features, and editing capabilities in both local containers and by deploying it to your XM Cloud environment.

The demo solution features many of the latest tech working together for us to play with:

  • Sitecore XM Cloud
  • Content Hub DAM and CMP
  • Headless SXA
  • JavaScript Services (JSS)
  • Next.js
  • Vercel
  • Tailwind CSS

Since the demo is available in the GitHub repository which means it is easily deployable with Deploy App in a few clicks, as demonstrated below.

Headless SXA

XM Cloud comes with a built-in headless SXA as well as it is included in the base XM Cloud container image, so the question comes up – should I go with it or without it?

Of course, it is possible to build a headless app on XM Cloud without using SXA, but it is not recommended. SXA provides many benefits and is included by default with Sitecore XM Cloud, so it is generally a better option for building a new site. If you are in a migration scenario, you may not have the option to use SXA, but other than that, it is recommended to use SXA and headless services for the best results.

There is an XM Cloud Starter Kit with Next JS for your faster journey to XM Cloud development.

Rendering Variants was always one of the most powerful features of SXA and it took its own evolution from NVelocity templates to scriban, now became powered with Next.js – here’s an example of a Promo component having two rendering variants – Default and WithText. You can have as many variants other than Default as you want within a *.tsx file following this syntax:

export const Default = (props: PromoProps): JSX.Element => {
  if (props.fields) {
    return (
    // ... markup merged with props 
  return <PromoDefaultComponent {...props} />;

SXA is perfect for multi-site implementations as it comes with cross-site capabilities for sharing page and partial designs, renderings, content, and cross-linking. In a previous post, I already mentioned a new feature – Page Branches – that allow setting standard values for layout on a per-website basis. Site-specific standard values feature is another example of managing default on a per-site basis. The development team is also working on implementing Site Templates – the idea comes about blueprinting the entire sites from pre-defined templates.

Speaking about the UI – by default, SXA comes with the grid system Bootstrap 5, but that is configurable. Default renderings respect both grid and styles through parameter templates, you must care of that once creating your own custom renderings unless, of course, you clone existing ones.

I remember a while ago when I only started working with SXA there was a lack of proper solutions around renderings having a background image set – we had to invent our own approaches to that. Slightly later SXA got that feature, but today I was glad to find support for a decent number of stretch modes with it: parallax, stretch, vertical and horizontal tiles, fixed. And all that works in headlessly!

Deploy App

Sitecore XM Cloud comes with an integrated Deploy App that performs exactly what is called for – deploying your solution using existing source code to XM Cloud from a friendly GUI as an alternative to using CLI. You can also create a project using a starter template.

choosing deployment method

In order to demonstrate its capabilities, let’s Start from your existing XM Cloud code, using Play! Summit demo mentioned earlier. Currently, the only provider to work with Deploy App is GitHub. So let’s go ahead with it.

deployment with github

After providing access to your GitHub account, you configure and choose the branch and the specific environment it deploys to if it is production or not. There is an option to trigger a deployment on commit to that branch to trigger an automatic deployment each time someone makes a push to the specified repository branch.

deployment with github parameters

That’s it! The deployment starts and makes things done automatically: provisioning tenants and environments, configuring Edge, pulling and building the codebase, deploying the artifacts, and eventually running post-build actions, if any.

deployment log

The whole process takes around 15 minutes and is impressive – the whole CI/CD pipeline comes out of the box, preconfigured. However, there’s one more thing left to do.

Deploying to Vercel

Since our head application is decoupled from Sitecore, we also need to deploy and reference it to Experience Edge. There are various options but the best would be using Vercel hosting. Vercel is the company that invented and maintains Next.js which is why their powerful hosting platform ideally fits solutions built with it.

Vercel is an all-in-one development platform that combines the best developer experience with an obsessive focus on end-user performance. As a developer-centric stack, Vercel is accessible to developers of all skill sets and removes a historical lock-in to .NET. Vercel provides a scalable solution to the largest of organizations with the newest best practices in content delivery while helping to reduce infrastructure/deployment overhead previously required to deploy Sitecore applications.

Deployment is pretty simple. Upon creating an account and project, you link your GitHub account and use the same repository used for XM Cloud deployment previously. Vercel is smart enough to autosuggest a folder with your next.js application highlighting it with an icon. After providing three familiar environmental parameters (App name, Edge endpoint, and API key for Edge token) deployment takes place quickly and then you’re all set!

Tip: do not modify .env file directly, instead - create an "override" file called .env.local. The difference is that in starterkits that file by default is excluded from source control with .gitignore, plus in addition to preventing mess with other developers, you can easily maintain your specific environmental setting in the same place.

XM Cloud also allows you to set up a Vercel hosting directly from its interface and add integration.

vercel setup hosting

If you do not have an account - you'll also be able to create one with quickly and easily, currently, there's only support for Personal Account types. Also, make sure you choose All Project access.

vercel link to vercel

You will still need to log in to Vercel and manually add GitHub integration to the same repository and branch, add a few more parameters, and at least 3 above environmental variables. Once done you can immediately trigger the deployment.

I hope this overview helps you familiarize XM Cloud development options and encourages you to try it earlier rather than later. Would you have any questions – please feel free reaching me!

Sifon - the easymost way of installing Sitecore XM/XP to your local machine

Hey folks, if you have not heard about Sifon for Sitecore - you must definitely check this out. It is a definite swiss army knife for local Sitecore development and you'd really like to learn why.

But here's a demo of how straightforward Sitecore installation is using the latest Sifon 1.3.3 release - you don't need to do anything at all rather than click a few buttons from UI. Below are the new features for this version:

  • added support for 10.3 version of the platform (downloads, Solr, dependencies, etc.)
  • added support for XM topology starting from 10.3
  • added SQL Server smooth installation in a single click
  • added convenient defaults so that you don't need typing at all, would you prefer the default setting
  • tested well on Windows 11
This tool is a gem for marketers, business analysts, and other non-developer groups of people who may need to set up Sitecore on their local machines but do not want to mess up with Docker and containers. Single-click smooth installation is what they want!
The installation itself is simple - either downloading the installer from the official website or even easier from Chocolatey gallery by this command:

cinst sifon
This 15-minute-long video shows it all in action - installing Sifon, then downloading and installing Solr, SQL Server, and Sitecore XP 10.3 with Publishing Service 7.0, SXA 10.3, and even Horizon from 10.2 - it works with 10.3 perfectly well, and installs in a single click, as everything else with Sifon:

Upon completion, Sifon will also automatically set up and activate the profile for the newly installed Sitecore instance (in the above image it is name xp and is also shown in the window title). Profiles are used to identify the active environment for the rest of Sifon functionality and plugins to operate against. One can easily switch active profiles from the dropdown and Profile editor menu.

I really hope this wonderful tool saves you lots of time and effort. Thanks for watching!

Update: occasionally, some rare systems report errors upon prerequisites installation. The error message prompts about being unable to identify and run AppPool task and is caused by the mandatory system restart requirement from IIS. For such systems, after the restart and re-running Sifon will work as expected. As an alternative, you may run the below command and restart your computer prior to using Sifon to ensure a smooth installation experience:
Enable-WindowsOptionalFeature -Online -FeatureName "IIS-WebServerManagementTools" -All

Sitecore Edge considerations for sitemap

A quick one today. We recently came across interesting thoughts and concerns about using Sitecore Edge. As you might know (for example from my previous post), there are no more CD servers when publishing to Sitecore Edge - think of that as just a GraphQL endpoint serving out json.

So, how do we implement a sitemap.xml in such a case? Brainstorming brought several approaches to consider:

Approach one

  • Create a custom sitemap NextJS route
  • Use GraphQL to query Edge using the search query. Here we would have to iterate through items in increments of 10
  • Cache the result on Vercel side using SSG

Approach two

  • Create a service from CM side that will return all published items/urls
  • This service will only be accessible by Azure function which will generate a sitemap file and store it in CDN
  • Front-end would then in this case access this file and render the content of it (or similar)

Approach three

  • Generate all the sitemaps (if more than a single sitemap) on CM, then store them all in single text fields
  • Returned them via edge, using GraphQL the font-end head which handles sitemap.xml

Then I realized, there is SXA Headless boasts SEO features OOB, including sitemap.xml. Let's take a look at what they do in order to generate sitemaps.

With 10.3 of SXA, the team has revised the Sitemap feature providing much more flexibility to cover as many use cases as only possible. Looking at /Sitecore/Content/Tenant/Site/Settings/Sitemap item you'll find lots of settings for fine-tuning your sitemaps depending on your particular needs. CM crawls websites and generates sitemaps. Then they get published to Sitecore Edge as a blob and then it gets proxied by a Rendering Host via GraphQL. When search engines request sitemaps of a particular website, Rendering Host gives them exactly what has been asked. That is actually similar to the above approach three with all the invalidation and updates of sitemaps provided also OOB.

This gives out a good amount of options, depending on your particular scenario.

Sitecore 10.3 is out! What's new?

On December 1st, after more than a year of hard work Sitecore has released its new version 10.3 of XM and XP platforms. 

Please note, that Experience Commerce sales have been discontinued after version 10.2 so unsure if there will be XC releases anymore. Historically XC releases follow up the platform releases with some lag of several weeks.

Let's take a look at what Sitecore put into the latest release.

With version 10.3 Sitecore moved in the direction of unifying its XM/XP platforms with XM Cloud. The two biggest proofs of that are SXA Headless and Integrated Web Hook architecture​ being a part of 10.3 - similar to XM Cloud.

Headless SXA

As you may hear, Headless SXA became a first-class citizen for XM Cloud. Now we get Headless SXA with 10.3 and new Next.js Headless SXA components, such as Container, Image, LinkList, Navigation, PageContent, Promo, RichText, Title, etc. SXA development team made an incredible job aiming to achieve feature parity for their product between XM Cloud and X/XP platforms. 

Because of that, the team sadly had to retire several features that do not fall nicely into a new concept - that's why Headless SXA doesn't use Creative Exchange any longer. The same comes valid for Forms - you will not be able to use them with Headless SXA  out-of-the-box, there is however documentation on how to use forms with Next.js, and is also one can also consider a dedicated forms builder. At the same time, SXA Headless brings some new concepts, like Page Branches and site-specific standard values. You may also want to leverage nextjs-sxa starter template (installs with npx create-sitecore-jss --templates nextjs,nextjs-sxa).

Among the new features, I like the ability to duplicate pages without subpages by clicking a right mouse button at a page, which may be helpful for cloning landing pages having multiple subpages without the unwanted routine of manually deleting cloned subpages afterward. Also, it works well with SEO concepts such as sitemaps, robots.txt files, redirect items and maps as well as error handling (for generating static 404 and 500 pages) - all that is extremely useful for almost any headless site.

In general, if you are planning a new implementation today and feel positive about using SXA, the best advice would be to download 10.3 and use the new headless SXA with it. That immediately brings you into the headless world of 2023 and drastically simplifies the further upgrade options, not to mention the potential migration to the XM Cloud.


That is a new introduction to the XM/XP platforms, while other Sitecore SaaS products which already use webhooks - XM Cloud, Content Hub, OrderCloud, etc. But firstly, what are webhooks? A webhook is just an HTTP request, triggered by some event in a source system being sent to any destination you specify, carrying some useful payload of data. Webhooks are automatically sent out when their event is fired in the source system. Basically, they are user-defined HTTP callbacks triggered by specific events. As per documentation, we are given 3 types of webhooks:

A good example of webhook usage may be validating and further canceling workflow transitions.

GraphQL Authoring and Management API

Another great new feature is GraphQL Authoring and Management API. This API provides a GraphQL endpoint for managing Sitecore content and performing some custom authoring tasks which previously one could do only with Sitecore user interface, almost any function. That means now we can automate operations around items (including media), templates, search as well as managing sites. Unfortunately, user management is not yet supported.

Sitecore Forms

Forms is the feature used on almost every solution I worked on, therefore it is a pleasure to see the new Embeddable Forms Framework. Using it one can add a Sitecore Form to any webpage, including pages that are not running on a Sitecore application - similarly to what FXM allowed doing. The good news is that an embedded form supports custom form elements and will not mess with any existing styles on a page as it is powered with Tailwind CSS. However, to benefit from Embeddable Forms you must have at least Headless Services 21.0.0 in place in order to deal with the Layout Service and also the endpoint for the data submission.


There is a new Data Export Tool that exports both contacts and interactions from the data database into files. It supports both Azure Blob and File Storage providers to be used for your deployments, but can also write into a network folder which is helpful for local instances.

Database Encryption

At the storage level, Transparent Data Encryption could be used with MsSQL Server to protect critical data by using data-at-rest encryption. In simple words, the data get encrypted prior to writing it into databases, so that physical SQL tables contain already encrypted data. When read-accessing, the data get transparently decrypted for authorized SQL users. It significantly protects the information, stored prevents data breaches, and complies with regulatory requirements for sensitive data.

What raised the event?

An interesting new feature helps us to identify which database raised a publish:end / publish:end:remote events will simplify updating the cache on remote CD instances.

Sitecore CLI

Version 5.0 of CLI has been around for a while since the XM Cloud release, now with its version 5.1.25 it became also an integral part of 10.3 platforms. It now supports Linux-based environments and features publishing to Edge, and features a few more new commands. It also employs integrated telemetry so that developers can improve CLI even further, however using telemetry can raise some security compliance concerns for governed environments.

What are the additional features we will see with the 10.3 release?

  • With version 10.3 of the platforms, Headless Services v21 comes into play. You may find a new starter kit for your new projects on Next.js 12.3.x over React 18.
  • Sitecore Host (along with components relying on it such as Publishing Service and Identity Server 7) were updated with .NET 6.0 which is an LTS version of a framework and has improved performance.
  • The supported version of Solr is now 8.11.2.
  • Those using EXM may now benefit from OAuth authentication with third-party services for custom SMTP.
  • Horizon, unfortunately, won't get any update beyond version 10.2. Despite technically it still works with 10.3 platforms, Sitecore discourages using it with 10.3 or later.
  • Management Services 5.0 offering publishing to Experience Edge now is capable of publishing a single item, and a few more improvements.
  • Search has got numerous improvements, like searching by ID and path, and searching for non-quotes-enclosed terms returns both exact and possible matches.
  • Windows Server 2022 support was promised but is slightly delayed, until January 2023. I assume support also relates to 2022-based containers in the first place, rather than underlying infrastructure.
  • More than 160 other issues submitted by customers were fixed and released in 10.3!

You can download and install Sitecore 10.3 right now, please feel free to share your thought on it!

Sitecore 10.3 dashboard

My 2022 Sitecore contributions

One more year has passed so quickly! I have just submitted my MVP application for the oncoming year and it actually took me a while to manage my contributions using the new format with a mandatory date selector. Not everything went submitted well there for me, so I decided to duplicate my submission in an open format, and maybe that will in some way help other new and potential applicants.

To start with, I need to mention that this year was very much special for me - I have relocated to the USA from England, UK for family reasons. But since my family is non-US, getting work authorization took an insane amount of time and effort, more than half a year took me to find a great place to work that could sponsor me an O-1 visa as the only possible solution to start work. Anyway, luckily the visa got granted and I recently started my new career path.

Learning and certification

So, having lots of time on a bench without any income, I still used my time wisely. I started the year by collaborating with [email protected] team (they made really good progress this year!) as well as learning new things myself. Between January and May, I cleared all the certification exams for each of the new Sitecore SaaS offerings. I also shared my learning & preparation in these blog posts: Content Hub, OrderCloud, and earlier there was also XP10.


But my biggest contribution went in a form of SUGCON presentation in Budapest, at the end of March. I picked up the difficult topic which lay in a shadow area - performing Sitecore XP/XM upgrades. There was a lot of controversial information on that subject, and previously I suffered it out myself on several projects. So I gathered all my knowledge as well as what I learned from colleagues and other MVPs and made a universal guide on approaching and performing platform upgrades. All the traps are mentioned, and following my guide may save at least 2-3 x times off the cumulative effort.

I also lodged good proposals for SUGCON ANZ and Symposium, however, those haven't been chosen for some reasons


If you haven't heard about it, Sifon is a must-have open-source tool for any Sitecore developer, to simplify most of your day-to-day DevOps activities. Beyond its OOB "install-backup-restore" features, empowered with a plugin system Sifon turns into a real Swiss army knife. Plugins reside in a separate repository that Sifon pulls with one click, everyone is welcome to create and pull-request their own plugins.

After XP 10.2 got released, I updated Sifon to support this latest version. It took me a few weeks in December-January to troubleshoot installing it to Windows 11, eventually, it all got implemented and a new version 1.2.6 became available (along with updated plugins). Thus, Sifon became the only GUI tool that could download and install XP on Win11 in just a few clicks, even easier than in containers.

Speaking at usergroups

I was invited to be a speaker at three Sitecore usergroups:

Sitecore Discussion Club

I organized the Sitecore Discussion Club only three times this year. Despite being a wonderful format of the event compared to traditional Sitecore user groups, it expanded most of its power in an offline format. With both founders having moved outside of the UK and living in totally different time zones, maintaining online events becomes a challenge. So much sadly we're thinking of closing it next year unless someone from the UK community takes it over from me.


Because of not having a work permit visa for such a long period, I was less exposed to the actual challenges and had fewer topics to blog about. There are still ~10 posts over the past year, and my blog homepage nicely indexes all the posts as they were written, reverse chronologically.

Sitecore Telegram

This year more effort went to Sitecore Telegram - a great channel with regular insights about Sitecore products on useful tips approaches ideas and concepts that are sometimes difficult to approach for Sitecore technology professionals - mostly developers, architects, and strategists - with around 800 subscribers in total. In 2022 I decided to expand Sitecore Telegram with 4 more additional channels exclusively dedicated to new SaaS products to promote those directly and channel out the audience attention: 


In the summertime I was invited to (and took part in) the two podcasts:

Sitecore Link project
When it comes to Sitecore.Link project - it could seem semi-abandoned at a first glance. That is partly true, but only partially. I still keep a fat bill in my pocket for the underlying infrastructure and anticipate the changes to save much on ownership costs. At this moment I am only adding some new content to the existing instance running on Sitecore 9.3 JSS. Big housekeeping is in scope to revise existing material that is no longer actual. For quite a long time I was thinking of rebuilding it with the proper technology, but nothing was much suitable.. until now! Next.js is a 100% ideal technology for this project. The backend is to be rebuilt for XM Cloud and to be interchangeable with 10.3+Edge and one of my biggest ambitions for 2023 would be to document the whole path in the format of a series of tutorials for typical Sitecore backend developers to "convert" into the new headless world.

Awesome Sitecore
Awesome Lists are the legendary curated lists about almost everything in the world, if you never came across it - please spend some time to see what it features. I am a creator and curator for the Awesone Sitecore list there for the past 3 years, classifying all the important and valuable open-source repositories we (as the community) have created so far. This is the best place to look up code for almost any Sitecore aspect one may be coding. This repository is gained 54 starts so far which is a great indicator of its value!

Organizing Los Angeles Sitecore User Group

After relocating to Southern California and commitments (plus presentation) for Los Angeles Sitecore UserGroup, I was invited to become a co-organizer for this event. I proudly accepted this request and now became a person in charge of this quarterly-run event. The next big event we do takes place on December 1-st just a few hours after the MVP application closes so technically it does not not count as a contribution for 2022.

MVP Summit
That is, in my opinion, the best perk of being a Sitecore MVP so I simply couldn't miss it! I shared some of my thoughts and vision (and some concerns as well) with the development teams and generally spent a great time learning lots of valuable information from other MVPs and Sitecore product teams

Other MVP-related activities

Over the past several years I have had a pattern of using my 1-to-1 half an hour with MVP Program to share the vision on platform development, business adoption, some Sitecore-related hot topics, and of course - the feedback to the Sitecore teams. I really hope it is been shared with the teams helping them to improve. Past December was not exclusion and we had a very productive conversation, as usual.

This year I took part in the Sitecore Mentor program (as a mentor). I wish we had more time spent together with my mentee. My biggest outcome is that unless you set up a recurring meeting invite that works for both of you - planning stays extremely difficult (given that we're both grown-ups with families and tons of responsibilities).

I also participated in MVP webinars and monthly MVP Lunch events as much as I could (given that my new timezone is a bit restrictive).

Lastly, as in all previous years, I helped out MVP Program with new applications and was happy to spot a few superstars on Sitecore horizon (no, not that one).

Future plans

Speaking about the plans for the next year, my new position requires me to get deeper with Sitecore and its products, with much more interaction and some shift-n-drift into strategy. I feel extremely positive about it!

Other than that:

  1. With no doubt, XM Cloud will be the headliner for 2023, not just for me, but for all of us. Now after finally getting access to the system I am so much eager to start blogging it backwards and forwards.
  2. SmartHub (especially the CDP part of it) has huge undiscovered potential, which I am anticipating coming across, luckily my new employer specializes in it.
  3. Content Hub is another product (also well-practiced at my company) for me to master, discover and blog about.
  4. XP platform is still with us, with lots of support required. Learning and documenting upgrade paths would be a hot topic fin 2023.

My learnings from project management and lead experience mistakes I came across

Recently I passed through a series of interviews for almost every of the top 10 Sitecore Platinum partners in the US. That was a wonderful experience, I learned lots about all these companies and their way of doing business. Moreover, I can definitely say now that organizations in their culture and temper are like humans - some are pro-active extroverts, while others are very pedantic process-oriented nerds.

One of the companies made me a set of a few ~1.5 hours-long interviews with a vice president baking me with lots of challenging but interesting questions, mostly management and business-related. As it usually happens, I keep thinking about it well beyond the time in the background, and my thoughts resulted in this post. I compiled that into a single solid dump of my experience, so here we go.


Take it as the rule of thumb: you have to spend resources on presale! The evaluation should be well detailed, not to receive a "negative profit" later. I remember a project when the assessment was done by the architect, who did not allocate enough time to study the Customer's processes in detail. He conducted most of the work "according to the standard", using the "best practices". As a result of poor quality assessment, the project received "negative margin".

At the stage of pre-sales evaluation of the project, it is necessary to provide a list of possible additional works (volume, cost, time). For example, a change in some indicators entails a restructuring of the entire model, which can take a significant amount of time, require the involvement of significant resources and cost decent money.


Integration evaluation also refers to the pre-sales evaluation of an upcoming project, but I emphasized this point intentionally.

First and most, you need to make sure that the systems do integrate with each other. Moreover, at the presale stage, it is crucial to find out as many details about the upcoming integration as possible: what systems, what protocols, buses, etc.

In another projects I took part in, the incompatibility of the external systems was discovered only at the stage of integration after work started. That resulted in the customer being unhappy with and additional labor costs for developing and configuring the alternative. Don't underestimate that!


Probably the most important stage with all the parties to be involved. Mistakes in the agreement may cost a lot!

1. It is crucial to ensure that the terms in the Agreement do match your resource plan. Why? It often happens that even at the presale stage of negotiating with a potential Customer, some additional clauses get added to the Agreement, and these changes get forgotten to be reflected into the resource plan. This is what happened in our project. The PM did not take part in the process of signing up the Agreement, and different participants in the process added each from themselves, but no one checked the compliance of the Agreement with the actual resource plan. As a result, a misalignment between the Agreement and Resource Plan led to time and labor losses that were not taken previously into account. Just doing an extra check would eliminate that loss and could save time and retain customer satisfaction!

2. When it comes to client training it makes sense to describe the learning process well in details in the Agreement. You may include a number of hours, topics, number, and type of users - also specifying business and/or technical users, as well as the list of attached instructions (including number, titles, etc.). No need to be ultra precise here, but the scope should be agreed upon and signed. Once in a time, our contract stated that we would provide instructions and provide training. But it ended up that the list of instructions and the amount of training planned by an Architect (why him, BTW?), mismatched the Client's expectations, and they demanded much more. This case is in fact a subset of the following point.

3. Try to avoid wording that could be interpreted differently. The presence of inaccurate wording may lead to ambiguity when the Customer insists on his understanding of the Agreement inaccuracies. According to the Agreement, during the data collection phase, the team supposed to hold an introductory workshop. However it turned out that no one knew what exactly should be shown. The customer expected that workshop to demonstrate the system in action with their actual data, so that potential users would understand how the system would work. Therefore preparation took a lot of extra time, not included in the initial project estimation. The lesson learned: when there is some uncertain clause in your contract with an unclear meaning or unknown implementation, it is better to immediately clarify what exactly this clause implies.

4. One more point relates to customer data or content. It is wise to specify that the Customer provides data in the required templates and formats in your Agreement. If that is not the case, then formatting/conversion work must be paid additionally. Once ago we had to load a large amount of data into the system. The Customer provided the data in the non-classified loose raw format. As a result, a large amount of labour spent on cleansing the provided data. That wasn't originally included in the estimate calculations and resulted with extra time and cost.

5. This clause is likely be found in the most of contract templates, however few people pay attention to it, sometimes delaying the deadlines. It pays to specify the deadlines or the amount of iterations for the approval. Any approval delays cause by the Customer should be recorded. By fixing these delays, you can win some extra time to adjust the deadlines if needed.

6. When it comes to change requests it helps to cap your maximum efforts in the Agreement. For example, stating that changes that require adjusting the architecture say more than 10% are provided for an additional fee. Most of the Agreement templates have this clause stated out in this or that way, though.

7. It goes without saying, however I spell it just in case. You must keep all communiaction with the Customer until the project completion and beyond a warranty period. Always note and take a record of any additional work outside of Agreement terms to be done to complete the project - at least time spent, reason, resources taken, etc.

Testing and Acceptance

1. All the acceptance criteria should be clear and known well in advance. 

2. When it comes to testing, the amount of effort should also be defined and signed well in advance. At least, types of tests, their order, and required resources from both sides.

3. It is often a case, when testing is due to start however the required access is missing or the testing environment is not ready, or not even provided (I am now writing about things to be provided by a Client) - this is to be recorder as mentioned before.

4. There might be more unpredicted cases like once the Client demanded most of their staff to take part in the delivery testing and the Agreement did not cover that case. The issue for us was that Client employees were in totally different time zones, which made us to adjust. Would that be predicted in the Agreement - there'd be a possible solution negotiated rather than getting this unpredicted at a cost of overtime for our Dev and Ops teams.

The above is just few of project issues I remembered but was still good to share.