Build better editor UX in composable CMSs with our Query API

The Enterspeed Query API enables native search indexes directly in Enterspeed. If you haven’t seen it yet, you can read more in our documentation or in the blogpost: The Enterspeed Query API is in preview.

But the Query API isn’t ”just” about search results – it’s a gateway to smarter orchestration across the tech stack. One of the use cases? A CMS Query Picker for composable architecture.

In this blog post we’ll show you how we used the Query API to create a custom content picker for Umbraco, rebuilding the editor experience – much like the one they had in monolithic platforms. And yes, we’ll walk you through every step 😊

The hidden cost of composable

Composable architecture has gained momentum in the last year and for good reasons. By decoupling content, presentation, and logic into specialised systems – such as best-of-breed CMSs, commerce platforms, search services, DAMs, and more – we gain agility, scalability, and future flexibility.

It all sounds good, but one thing is often forgotten in the composable architecture, and that’s the editor experience.

 
The simplicity of the monolith

In traditional, monolithic digital experience platforms (DXPs), content lived in one place. Editors could build pages, link to articles, pull in media, or reference a product – all with a simple content picker. They didn’t need to know or care where the data came from. It was all there, neatly organised, searchable, and cross-referenced. Editing was intuitive.

The composable trade-off

In composable solutions, the landscape has changed. Content is no longer centralised. The product data might live in a PIM. The blog in a headless CMS. The image in a cloud DAM.

As a result, referencing content becomes complicated. Editors can't just pick content. Instead, they need to know where it lives, and in some cases, copy/paste IDs or URLs.

Bringing back the content picker

In a composable setup, one of the biggest missing pieces for editors is a unified way to search and select content – which is something they used to do effortlessly in traditional platforms using a simple content picker. That's where the Query API and our orchestration layer come in.

At Enterspeed, bringing together data from multiple sources like CMSs, PIMs, ERPs, and CRMs is kind of our baseline. With all this structured data available in a single place, it became clear: We could expose it via the Query API and plug it into a custom content picker – bringing back a core piece of the editorial experience. 

Demo time

To explore this idea, we created a small demo project: A custom property editor for Umbraco. Since many of our customers use Umbraco, it made sense to start there.

We began by creating three separate indexes in Enterspeed:

• One for content pages from a CMS
• One for products from a PIM
• One for customers from a CRM 

Once indexed, we built a flexible property editor in Umbraco. It’s configurable which allows you to create multiple query pickers, each targeting a different data type.

You simply choose:

• Which index to query
• Which field to search
• Which field to display in the picker

We then created three Umbraco Data Types – one for each index – and added them to different content properties. Just like that, editors could now select and reference data across systems, directly inside the Umbraco backoffice.

The result? A smooth, unified editing experience, even in a deeply composable architecture. No jumping between systems. No manual ID copy-pasting. Just pick the content you need.

What’s next?

We originally built the property editor as an experiment – to test the flexibility of the Query API and explore new ways to improve the editor experience in composable setups. But it definitely feels like a nice and easy way to make the editors happy again.

Right now, the project is available as open-source on GitHub:👉 Enterspeed Umbraco Query Picker

If you'd like to see this become a fully Enterspeed supported NuGet package, let us know, and we might be able to do just that 😊