Optimizing Publishing V2 in Sitecore AI: Content Dependencies, Templates & Experience Edge

Hello everyone, and welcome to another blog post. Today we'll explore something interesting about the new publishing approach introduced in Sitecore AI. Specifically, we'll look at the settings worth enabling early — during template creation and development — to save yourself from unnecessary rework down the line when working with Edge Runtime publishing (V2).

If you have moved to Publishing V2 in Sitecore AI (XM Cloud) and noticed that edits to a referenced or child item don't always make it to Experience Edge, you are not imagining it. Publishing V2 is built for speed, and by default it favours smaller, faster publishes over exhaustively scanning every related item (Basically in Snapshot publishing). That trade-off is great for performance, but it can leave your published content "less complete" than you expect.

This post walks through the settings that control how thoroughly Publishing V2 resolves dependencies, and the exact steps to make sure related and child items publish correctly.

Why related items sometimes don't publish

In Publishing V2, whether Sitecore chases down related and referenced items is governed by a handful of settings and environment variables. When these are turned off, publishing is quicker because Sitecore simply processes fewer items — but the cost is completeness. Two environment variables are worth knowing about:

• XMCLOUD_ENVIRONMENT_PROCESSRELATEDITEMS=false
• XMCLOUD_ENVIRONMENT_DEPENDENCYANCESTORS=false

And on the classic publishing side:

• Publishing.DeepScanRelatedItems=false — with deep scanning disabled, Sitecore publishes fewer items for speed, but the publish can be less complete because it does not scan for every possible related-item change.

In short: faster publishes, but a datasource change buried a few references deep may not trigger everything it should. The fix is to let Experience Edge compute content dependencies and to make sure your datasource templates report revision changes correctly.

Step 1 — Enable content-dependency computation

The key setting is ExperienceEdge.ComputeContentDependencies. Enabling it tells Experience Edge to include referenced and related items from a datasource item when publishing, so the graph that Edge serves stays consistent with your authored content.

You can set it either as a Sitecore setting:

ExperienceEdge.ComputeContentDependencies=true

…or as the equivalent environment variable:

Sitecore_ExperienceEdge_dot_ComputeContentDependencies

Important: after enabling this, perform a full site republish to Experience Edge. The dependency graph needs to be rebuilt once so that Edge knows about the relationships going forward.

Step 2 — Tell Sitecore which field types create dependencies

Content dependencies are only as good as the field types Sitecore treats as links. The ExperienceEdge.LinkDependentTypes setting defines which field types are followed when computing dependencies. Make sure it covers all the reference field types you actually use:

<setting name="ExperienceEdge.LinkDependentTypes">
  <patch:attribute name="value">droplink|droptree|grouped droplink|checklist|multilist|multilist with search|treelist|treelist with search|treelistex|multiroot treelist</patch:attribute>
</setting>

If you have a custom reference field type, this is the list to extend — otherwise changes made through that field won't be picked up as dependencies.

Step 3 — Fix the datasource template so revisions update

Here is the subtle one. For a datasource item's revision to update correctly when a child item is modified, the template used by the datasource item needs the right base templates. Add these two base templates to it:

• _HorizonDatasourceGrouping
• _PublishingGroupingTemplate

For reference, the template IDs are:

Template	ID
_HorizonDatasourceGrouping	{D0F6BE14-2A2D-4C56-ACB5-80CAA573B8E2}
_PublishingGroupingTemplate	{8BA7DAC6-32ED-4378-BD9E-5DA5B0F9848D}

The process is straightforward:

1. Open the template used by your datasource item.
2. Add _HorizonDatasourceGrouping and _PublishingGroupingTemplate as base templates.
3. Save the template.
4. Publish the affected items.

Once these base templates are in place, modifying a child item will correctly bump the datasource item's revision, which is what tells the publishing pipeline something has changed.

Putting it together — a quick checklist

1. Confirm your Publishing V2 settings are enabled.
2. Set ExperienceEdge.ComputeContentDependencies=true (or the matching environment variable).
3. Review ExperienceEdge.LinkDependentTypes and add any missing reference field types.
4. Add the two base templates to your datasource template, save, and publish.
5. Run a full site republish to Experience Edge once, so the dependency graph is rebuilt.
6. Decide consciously on your speed-vs-completeness settings (Publishing.DeepScanRelatedItems, XMCLOUD_ENVIRONMENT_PROCESSRELATEDITEMS, XMCLOUD_ENVIRONMENT_DEPENDENCYANCESTORS).

The trade-off to keep in mind

Every one of these settings is a lever on the same balance: publish speed versus publish completeness. Turning dependency processing off gives you faster, leaner publishes and is perfectly fine when your content is largely self-contained. Turning it on — with the right templates and link types configured — makes your publishes more thorough, at the cost of more work per publish.

For most content-heavy Sitecore AI implementations that lean on shared datasources and reference fields, enabling content-dependency computation and fixing the datasource templates is well worth it. It's the difference between wondering why an edit didn't show up on the site, and trusting that what you publish is what your visitors get.

Thanks for reading. Keep learning and keep sharing.

You can check my other blogs too if interested. Blog Website

References:

• https://doc.sitecore.com/sai/en/developers/sitecoreai/content-modeling-and-presentation/sitecoreai-for-developers/pages-configuration/add-the-manage-items-section-to-pages-for-a-custom-component.html