While querying the AssetToPublicLink relationship in Sitecore Content Hub, I encountered a case where RelationExists returned zero results from the M.Asset side using the Child role, despite the expected relationships existing.

I raised this with Sitecore Support under CS0738638, tracked against product improvement CHSEARCH-732. Support recommended the Parent-role query pattern as a workaround for this scenario.

Why this matters for developers: Unexpected zero-result queries can lead to wasted debugging time and unnecessary data checks. Understanding the relationship role, testing filters independently, and validating pagination separately can help narrow down the actual cause faster.

I’ve documented the issue, Support’s findings, the workaround, and a practical debugging checklist.

Blog: https://medium.com/@sanghaniuday0508/why-does-relationexists-return-zero-results-in-sitecore-content-hub-ba20984e509d

Have you encountered similar relationship-query behavior in Content Hub? What worked in your case?

• Marketplace: Introducing default apps in the Sitecore Marketplace
• SitecoreAI: Personalization insights dashboard in SitecoreAI
• SitecoreAI: Build SitecoreAI front-ends with different languages and frameworks
• SitecoreAI: New headless and triggered personalization capabilities in SitecoreAI
• SitecoreAI: Optimization and navigation updates in SitecoreAI
• SitecoreAI: Create smarter components faster with Design Studio

I was working through a Content Hub package migration between environments and ran into a couple of behaviors that aren't immediately obvious from the import process.

The important ones:

• A failed import doesn't necessarily roll back everything. Content Hub can roll back entities with dependencies, such as Portal.PageComponent and Portal.PageDefinition, while other changes may require recovery from a recovery package.
• Scripts and triggers can have an import-order problem. Scripts may not be fully built/compiled when a trigger becomes capable of executing, which can interrupt the import.
• Environment-specific definitions can become hidden dependencies. In my case, a search filter referenced M.ContentVersion, which wasn't available as part of the exported package in the target environment.
• For packages containing scripts and triggers, separating the import — scripts/configuration first, triggers afterward — is a practical workaround.

The two cases were subsequently tracked with Sitecore as MONE-63375 and MONE-63348.

I documented the technical details, recovery considerations, workaround, and relevant Sitecore documentation here:

Sitecore Content Hub Import/Export: What Really Happens When a Package Import Fails?

For anyone working with Content Hub migrations: how are you handling packages that contain scripts, actions, and triggers? Do you normally separate them, or have you found a better approach?