Apr 18, 2026Sitecore AISitecore PagesSitecore XM CloudMediaValetDAM

Using the Sitecore AI Plugin Field with MediaValet in Sitecore Pages

I recently worked on a project where one requirement shaped the entire image authoring story: all images needed to come from a third-party DAM, MediaValet.

That made this a good opportunity to use the new Sitecore AI Plugin Field and learn what it looks like to wire a custom Sitecore AI App into a real authoring flow. I am not going deep on the Sitecore AI App implementation in this post. Assume the app already exists, is hosted on Netlify, and is configured as a custom field for Page Builder.

The interesting part here was not just opening a custom app from Pages. It was making the full workflow feel natural for content authors and making sure the selected asset still worked with the page editor and front-end components.

The Goal

The requirement was simple:

Authors should browse MediaValet instead of Sitecore Media Library.
Templates that require images should use the Plugin Field.
The selected asset should flow into the rendering layer without custom authoring steps.

Once that direction was clear, the Plugin Field became the right fit.

Start with the Sitecore Template

Because the DAM had to be the source for all images, any Sitecore template that normally would have used an image field needed to use the Plugin Field instead.

The key configuration is the source field on the Sitecore template field definition. That source value needs to be the GUID of the custom Sitecore AI App.

That GUID is how Sitecore knows which app to load during content authoring.

So the basic setup looked like this:

Create or identify the custom Sitecore AI App.
Configure it as a custom field for Page Builder.
Host the app externally, in this case on Netlify.
Update Sitecore template fields that need DAM-backed images to use the Plugin Field.
Set the source field to the app GUID.

Without that source GUID, Sitecore has nothing to point to when the editor opens the field.

What Authors See in Pages

Once the field is configured, the experience in Sitecore Pages is pretty straightforward.

In the field editor, the Plugin Field shows up as a text box with a button labeled Open App.

When the author clicks that button, Sitecore opens a pop-up window and loads the custom Sitecore AI App. In our case, that app hosted the MediaValet integration and presented a media browser and picker.

From there, the author can browse MediaValet assets, pick an image, and let the custom app return the field value back to Sitecore.

Plugin Field In Pages, showing the Open App Button

The Value Returned from the Custom App

When an author selected an image in MediaValet, our custom app returned a JSON object that looked like this:

{
  "src": "https://mvsfservicefabricusva.blob.core.windows.net/medialibrary-......png",
  "alt": "",
  "height": 1350,
  "width": 1080,
  "title": "Image title"
}

That structure turned out to be the most useful part of the implementation.

If you have worked with Sitecore ContentSDK or XM Cloud front ends, that shape should look familiar. It is effectively the same structure used by the inner ImageField value that the React image component expects.

That meant we did not need to invent a parallel image contract. We just needed to preserve a compatible payload and parse it at the right point in the rendering flow.

The Next Challenge: Make It Work in the Page Editor

Getting the Plugin Field to save JSON was only half the job. The next challenge was making those images work properly in the Page Editor and in the normal rendering flow.

In our projects, we already use a wrapper around the image field rather than binding components directly to the raw Sitecore field shape. That turned out to be the right extension point.

Because the plugin value already matched the image field payload closely, all we needed to do was parse the JSON string before passing it to the component.

The pattern was roughly this (This is just an example code.):

type PluginImageValue = {
  src: string;
  alt?: string;
  height?: number;
  width?: number;
  title?: string;
};

function toImageFieldValue(value?: string) {
  if (!value) {
    return null;
  }

  try {
    const parsed = JSON.parse(value) as PluginImageValue;

    return {
      value: {
        src: parsed.src,
        alt: parsed.alt || parsed.title || "",
        height: parsed.height,
        width: parsed.width,
      },
    };
  } catch {
    return null;
  }
}

The exact implementation will vary based on your component model, but the main idea is the same:

Read the Plugin Field value as a string.
Parse the JSON safely.
Map it into the image field structure your React components already understand.
Keep the wrapper responsible for that transformation so the rest of the component tree stays clean.

That approach let us support DAM-backed images without rewriting every component that already expected a normal image field.

Plugin Field working as an image in Pages

Why This Worked Well

A few things made this pattern practical:

It kept authoring inside Pages

Authors did not have to leave Sitecore Pages or follow a separate DAM synchronization process. They clicked Open App, picked an image, and kept moving.

It avoided a front-end rewrite

Because the payload aligned with the image component's expected structure, the integration work stayed focused in one place. We did not have to rework every rendering that consumes an image.

It gave the DAM team control where they needed it

The client wanted MediaValet to remain the system of record for images. The Plugin Field made that possible without forcing Sitecore to own the assets directly.

Things to Watch For

If you try this pattern, these are the details I would pay attention to first:

Make sure the Sitecore template field source contains the correct Sitecore AI App GUID.
Decide on a stable JSON contract early so your app and front end do not drift apart.
Handle invalid or empty JSON defensively in your image wrapper.
Test the experience in Sitecore Pages editing mode, not just in the final rendered site.

Final Takeaway

This was a good use case for the Sitecore AI Plugin Field. It gave us a clean way to launch a custom Sitecore AI App from Pages, let authors browse MediaValet assets, and return image data in a format the front end could already use.

The Sitecore AI App itself is its own topic, but once that app exists, the Plugin Field becomes a practical bridge between external authoring tools and Sitecore Pages.

For this project, the most important design decision was keeping the returned payload aligned with Sitecore's image field shape. That is what made the DAM integration feel much lighter than it could have been.

Share this post