Optimizely Graph (Optimizely.Graph.Cms) — IContentIndexer made in

Optimizely Graph (Optimizely.Graph.Cms) — IContentIndexer made internal in 13.3.0+, no public API to trigger on-demand reindex of a specific content

Sunil

workspace_premium

Vote:

expand_less 0 expand_more

Hi,
We're on CMS 13.3.0 / Commerce 15.2.0, using Optimizely Graph (Optimizely.Graph.Cms / Optimizely.Graph.AspNetCore / Optimizely.Graph.Commerce, all 13.3.0/15.2.0).

In 13.0.0–13.2.0, Optimizely.Graph.Cms.Content.IContentIndexer and IndexableContentReference were public, and we used them to push a specific content item to Graph on demand — e.g. after an external system syncs inventory data outside the normal CMS publish flow, and we want that item's Graph index refreshed immediately rather than waiting for the next scheduled sync.

As of 13.3.0, both types are internal (confirmed via reflection on the actual assemblies, not just docs — and this holds all the way through the current 13.5.1). We can't find any public API anywhere in the Optimizely.Graph.* packages that replaces this.

From what we can tell, the supported model now is purely event-driven: content gets reindexed automatically by an internal EventIndexer when it goes through the normal publish pipeline (IContentRepository.Save(..., SaveAction.Publish, ...)), plus a periodic internal job that catches anything missed. Our current workaround is to republish the affected items (SaveAction.Publish | SaveAction.ForceCurrentVersion, so we don't bloat version history) purely to force them through that pipeline — but this also fires every other PublishedContent subscriber for that content type, and adds real latency when republishing many items in a batch.

Questions for anyone who's hit this:

Is there a currently-supported way to trigger a Graph reindex of a specific content item without a full publish/Save?
Is manual/on-demand indexing intentionally gone for good as of 13.3.0, or is there a roadmap item for a public replacement?
If republishing is really the intended approach for "externally-driven data changed, reindex this item now," is there a lighter-weight way to do it that doesn't fan out to unrelated publish subscribers?
Any recommended pattern for doing this efficiently in bulk (hundreds of items per sync run) rather than one Save call per item?

#343766

Edited, Nov 06, 2026 11:41

Quan Mai

Vote:

expand_less 0 expand_more

It is the intention. Some CG developers could explain better than me but it's intentional that the indexing to CG will be "seamless" - e.g. automatically without manually triggering it.

If you have to, then you can workaround by trigger a publish event via IContentEvents.RaiseContentEvent. It's not optimal but should work for your purpose.

#343767

Nov 06, 2026 11:46

Sunil - Nov 06, 2026 11:55

Thanks Quan, for confirming — that's helpful to know it's intentional.

The publish-event workaround makes sense and we can use it if needed, but I wanted to check if it's really the only option. Our concern is that triggering a full publish just to refresh one field in Graph means republishing the entire product/variant content item — not just the field that changed.

At the scale we're working with (potentially hundreds of SKUs per sync batch), that could add meaningful latency and also fires every other PublishedContent subscriber (cache invalidation, sitemap jobs, etc.) for each item, not just the Graph indexer.

Is there any lighter-weight option for refreshing a single field/value in Graph without going through a full content publish? Or is a full publish genuinely the only supported path today, even for high-volume/frequent updates like inventory levels?

Appreciate the guidance.

Quan Mai - Nov 06, 2026 12:26

It's the lightest option out there and it is being used in Commerce content graph. I've consulted our lead engineer on CG and he agreed that is the way.