Editing Adobe Journey Optimizer Emails with Universal Editor

How universal is Universal Editor? Could it also work for editing emails in Adobe Journey Optimizer?

This proof of concept explores that idea. It's a small custom app that renders AEM Content Fragments inside an email preview, makes the content editable through Universal Editor, and pushes the resulting HTML to Adobe Journey Optimizer (AJO).

The workflow is simple: load the content, edit it in the email, and push it to AJO when it's ready. AEM remains the home for the structured content, while the app handles the preview and the handoff to AJO.

Bringing content into the email preview

Working with HTML emails involves a lot of switching between editing, previewing, and sending proofs. When the content comes from AEM Content Fragments, there is another layer to keep track of: the relationship between the content in AEM and what appears in the email.

If you're looking at personalization expressions instead of the actual copy, it's hard to tell how a headline or CTA will fit. You end up switching tools just to check a small change.

AEM Content Fragments keep the content structured and reusable. The app puts that content into the email layout so authors can see their changes as they work.

How the app works

The workflow has three parts: render the email, edit its content, and push the result to AJO.

1. Render an email with real AEM content

The app combines an MJML/HTML Email template with data from AEM Content Fragments. The template defines the email layout, while the fragments supply content for its predefined fields.

To keep the POC simple, the template uses MJML (Mailjet Markup Language). It provides reusable components for responsive emails and handles much of the nested HTML tables and CSS work behind the scenes. That keeps the focus on the editing workflow without getting bogged down in email markup.

The app compiles the template into HTML and renders a preview. Authors can see the actual copy in place: how a headline fits, how much space the body text takes, and how a CTA reads alongside the rest of the message.

2. Edit the content inside the preview

The preview opens in Universal Editor, which provides the editing interface.

Click an editable field, such as a headline or CTA label, and change its value. The edit is saved back to the corresponding content resource in AEM, and the preview refreshes with the updated content.

This is the main authoring benefit: the content stays structured in AEM, but authors work with it where they can see how it fits into the email.

3. Push the updated email to AJO

Once the content is ready, the app can push the compiled HTML into AJO content templates through the AJO API.

Saving an edit in AEM and pushing the template to AJO are separate steps. You can work on the content, check the preview, and then push the result when it's ready.

What connects the pieces

The app handles the rendering and AJO integration. Universal Editor supplies the controls for editing the content displayed by the app.

mermaid
flowchart TD
    AEM["AEM Content Fragments"] -->|"Content via AEM API"| APP["Custom app"]
    APP -->|"Instrumented email preview"| UE["Universal Editor"]
    UE -->|"Save edits via UE Service"| AEM
    APP -->|"Push HTML via AJO API"| AJO["AJO content templates"]

The app reads content through the AEM API, combines it with the MJML/HTML email template, and exposes an instrumented preview for Universal Editor. The AJO API provides the separate path for pushing the finished template.

To make that possible, the preview includes Universal Editor instrumentation. Attributes such as data-aue-resource, data-aue-prop, and data-aue-type identify the content resource, the field being edited, and the type of editing control it needs.

That mapping connects a visible element in the email to a specific field in AEM. Edits pass through the Universal Editor Service to the underlying content resource; the app reads the content to render the preview.

Where this approach helps

This setup is useful when a team already manages content in AEM and uses repeatable email layouts. Authors can update copy, labels, and other exposed fields while seeing the surrounding email, and developers can maintain the template separately.

The layout stays in the email template. Authors work on the content inside it, so changing a headline doesn't mean touching the email's structure.

A browser preview also has its limits. It helps authors judge content and layout as they work, but the resulting email still needs testing in clients such as Outlook, Gmail, and Apple Mail. Proof sends and email rendering checks remain part of the process.

From proof of concept to a team tool

The proof of concept gets the core workflow working. Before a team could use it day to day, there's more to do around deployment, sign-in, and permissions.

The next step would be to move the app to Adobe App Builder and set up proper authentication and access controls. That means defining who can open the app, edit content, and push templates to AJO, as well as configuring the permissions for the AEM and AJO integrations.

The interface could also move to React with React Spectrum, Adobe's component library. That would give the app familiar, accessible controls and help it feel at home alongside the other Adobe tools authors already use.