Experience Fragment Architecture — Reusable Experiences Across Channels

Content Objective

In this chapter, you'll understand:

• What Experience Fragments are and how they differ from Content Fragments
• The XF variation system and why it matters for multi-channel delivery
• How to set up templates for Experience Fragments
• Social media and email delivery patterns
• Real production use cases where XFs save significant time
• Common mistakes teams make with Experience Fragments

Where We Are

We've covered Content Fragments — structured data without layout. Now let's talk about a commonly confused sibling: Experience Fragments.

The confusion between Content Fragments and Experience Fragments is real. One of the most common questions developers ask is whether they should use a Content Fragment or an Experience Fragment. At first glance they seem similar, but they solve very different problems. Here's the one-line summary to cut through that debate:

• Content Fragment = Content without layout (data)
• Experience Fragment = Content with layout (a designed experience)

That distinction changes everything about when and how you use them.

Imagine you're managing an e-commerce website.

The marketing team launches a "Summer Sale" campaign.

The same promotional banner needs to appear on:

• Home Page
• Category Pages
• Landing Pages
• Campaign Microsites

A developer could simply copy the banner onto every page.

Initially, this works.

A month later, the campaign changes from:

"20% OFF"

to

"30% OFF"

Now someone has to update every page individually.

This is exactly the problem Experience Fragments were designed to solve.

Instead of copying content across pages, AEM allows teams to create a reusable experience once and reference it wherever it's needed.

Every page displays the same experience, while the content is managed from a single location.

What an Experience Fragment Is

An Experience Fragment (XF) is a component or group of components — with a visual layout — that can be reused across multiple pages or channels.

Think of it as a self-contained piece of a page that you can drop anywhere.

Common examples:

• A promotional banner with headline, image, CTA button
• A newsletter signup block with form, image, and legal text
• A footer that needs to appear on 200 pages
• A cookie consent bar used site-wide
• A product promotion block used across multiple category pages

Where They Live

/content/experience-fragments/
└── [project]/
    └── en/
        ├── promotions/
        │   └── summer-sale-banner
        │       ├── master (variation)
        │       └── email (variation)
        └── footer/
            └── global-footer
                ├── master (variation)
                └── amp (variation)

Unlike Content Fragments which live in the DAM, Experience Fragments live under /content/experience-fragments. This is important — they have their own page-like structure because they contain layout and components.

Unlike Content Fragments, Experience Fragments contain actual AEM components.

If you open an Experience Fragment in CRXDE, you'll see the same component nodes that you would find under a normal page.

Inside an Experience Fragment you won't find fields such as Title or Description.

Instead you'll find the same components that authors use on normal pages.

For example:

• Summer Sale XF

• Title Component

• Image Component

• Button Component

• Container Component

This is why Experience Fragments are stored under:

/content/experience-fragments

instead of

/content/dam

Content Fragments store structured data.

Experience Fragments store reusable page experiences.

The XF as a Page

An Experience Fragment is essentially a mini page. It has:

• Its own template
• Its own components
• Its own content (authored inline)
• Its own publication state

When an author edits an XF, they use the same page editor they use for regular pages. Drag, drop, configure — exactly the same authoring experience.

Variations

Variations are what make Experience Fragments powerful for multi-channel delivery.

One Experience Fragment can have multiple variations, each targeting a different channel:

Summer Sale Banner (XF)
├── master (web, full layout)
├── email (email-safe HTML, no scripts)
├── social-facebook (1200x630 image focus)
├── social-twitter (1:1 square crop, short copy)
└── amp (AMP-compliant HTML)

Each variation shares the same core concept (the summer sale) but is designed for its specific delivery context.

A common misconception is that every variation automatically stays synchronized with the master variation.

That's not how most production projects work.

The master variation usually provides the starting point.

Individual variations can then override layout, images, or channel-specific content while still representing the same business campaign.

Architects decide what should remain shared and what should vary between channels.

Why Variations Beat Duplication

Before variations, teams would create five separate components for five channels. When the campaign message changed ("20% off" → "30% off"), someone had to hunt down all five and update each one.

With variations, the content lives in one XF. The master variation has the canonical version. Other variations inherit or override specific properties.

When the offer changes, an editor updates the master. If the variations are set up correctly, they inherit the core content change automatically.

Part 3: Template Setup

Before anyone can create an Experience Fragment, you need to set up XF templates — similar to how page templates work.

Creating an XF Template

XF templates are configured under:

Tools → General → Templates → Experience Fragment Templates

A well-designed XF template setup:

Experience Fragment Templates
├── Web Fragment (for site components, full CSS/JS)
├── Email Fragment (stripped HTML, inline styles, no scripts)
├── Social Fragment (image-heavy, minimal text)
└── AMP Fragment (AMP-compliant constraints)

Each template specifies:

• Which components are allowed (policies)
• Page component that wraps the XF
• Initial content defaults

The XF Page Component

XFs need their own page component, separate from your regular page component. This component:

• Renders the XF without the full site chrome (no header, footer)
• Applies channel-specific CSS
• Handles export formats (HTML for email, JSON for integrations)

/apps/myproject/components/xf-page
├── .content.xml  (resourceType + componentGroup)
└── xf-page.html  (minimal wrapper, no site nav)

How XFs Are Used on Pages

The most common usage: dropping an XF into a page using the Experience Fragment component (from AEM Core Components).

Page Layout:
├── Header Component
├── Hero Component
├── [Experience Fragment Component]  ← references /content/experience-fragments/...
│   └── renders: Summer Sale Banner
└── Footer Component

When the editor places an XF component on a page, they pick which fragment (and which variation) to use. The fragment renders inline, looking identical to any other component.

The power: if you update the XF, every page using it gets the update immediately. No need to find and edit 50 pages.

What Happens During Rendering?

When a page containing an Experience Fragment is requested, AEM follows the same rendering lifecycle used for any other component.

The difference is that the Experience Fragment component references another piece of content instead of rendering its own content.

The rendering flow looks like this:

Although an Experience Fragment feels like a reusable page section, it still participates in the normal Sling rendering pipeline.

Multi-Channel Delivery

Experience Fragments were designed to support content reuse across multiple delivery channels.

In many enterprise projects, the same campaign needs to appear on:

• Website
• Email
• Landing Pages
• Adobe Target
• Marketing Automation Platforms

Instead of recreating the campaign for each channel, teams create different Experience Fragment variations that can be consumed by the appropriate platform.

Depending on the organization's architecture, these variations may be integrated with Adobe Campaign, Adobe Journey Optimizer, Marketo, or other marketing tools.

The important idea isn't the integration itself.

It's that the same experience can be reused across multiple channels without rebuilding it each time.

What This Solves

Without XFs, marketing teams maintain content in two places: AEM for the website, Hootsuite/Buffer/native apps for social. When a campaign message changes, they update both. Inevitably, the updates drift.

With XF social posting, the website and social content come from the same source. The team configures it once per campaign, not twice.

Email Delivery

Email is notoriously difficult to get right with HTML. Email clients don't support modern CSS, scripts are blocked, and layout quirks are everywhere.

The email variation of an XF handles this:

• Templates restrict components to email-safe ones
• Styles are inlined (no external CSS)
• No JavaScript
• Tables instead of flexbox/grid (for Outlook compatibility)
• Images use absolute URLs (email clients can't resolve relative paths)

When an email variation is ready:

XF Editor → Export → Export as Email HTML

The exported HTML can be pasted into your email platform (Marketo, Eloqua, Campaign), or if you have a direct AEM integration, it publishes automatically.

Real-World Use Cases

Use Case 1: Global Footer

Problem: A company has 15 country sites. The footer has legal disclaimers, nav links, and a copyright notice. The legal team updates disclaimers twice a year. Before XFs, an editor updates 15 pages every time.

Solution with XFs:

/content/experience-fragments/footer/
├── global-footer (master)
├── us-footer (US-specific legal)
├── eu-footer (GDPR notice)
└── uk-footer (UK-specific disclaimer)

Each site's footer page references the relevant XF footer. Legal updates the appropriate XF. All pages using that footer update automatically.

Result: What was a 2-day editorial task became a 5-minute update.

Use Case 2: Promotional Banners

Problem: An e-commerce site runs 12 promotions per year. Each promotion needs a banner on the homepage, category pages, and search results. Plus a Facebook post, an email teaser, and an in-app notification.

Solution with XFs:

XF: Black Friday 2026 Promotion
├── web-banner (homepage, category, search)
├── email-teaser (email header)
├── social-facebook (campaign post)
└── social-instagram (square format)

Marketing creates the promotion once. The web team places the web-banner XF on homepage and category pages. The email team exports the email-teaser variation. Social goes out via the social posting integration.

Result: One content creation effort, four channel deliveries.

Use Case 3: Cookie Consent

Problem: GDPR requires a cookie consent banner. Different regions have different requirements (EU vs US). The legal text updates occasionally.

Solution with XFs:

XF: Cookie Consent
├── eu-consent (opt-in by default, full GDPR language)
└── us-consent (opt-out option, simplified language)

The template includes the consent XF component, conditionally rendering the right variation based on geolocation. Legal updates the XF. All pages get the update on next publish.

XF vs Content Fragment — The Decision

Here's the practical decision guide:

Real decision shortcut:

• If a developer consumes it (API, code) → Content Fragment
• If an editor places it on a page → Experience Fragment

Production Troubleshooting

Problem: XF Changes Not Reflecting on Pages

Symptom: Editor updates an XF, but pages using it still show old content.

Root Cause: The page isn't being invalidated when the XF is published.

Fix: Check your replication configuration. AEM should trigger page invalidation when referenced XFs are published. If not:

Tools → Replication → Agents → Default Agent → Test Connection

Also verify that the page component is actually rendering the XF at request time and not caching the XF HTML in the page's own cache.

Problem: Social Posting Fails

Symptom: "Post to Facebook" throws an error or silently fails.

Root Cause (most common): Social channel cloud service configuration is expired or misconfigured. Facebook and Twitter tokens expire.

Fix:

Tools → Cloud Services → Social Media Configurations

Re-authenticate the social accounts. Facebook access tokens expire after 60-90 days unless you have a long-lived token.

Problem: Email Variation Renders Incorrectly in Outlook

Symptom: The email looks great in Gmail but broken in Outlook.

Root Cause: CSS properties that aren't supported by Outlook's rendering engine. Flexbox, grid, modern CSS selectors.

Fix: Your email XF template needs components that use table-based layout and inline styles. Review your email template's allowed components and ensure they're genuinely email-safe. Tools like Litmus or Email on Acid can test across clients.

Problem: Authors Can't Find XF Templates

Symptom: Authors go to create a new Experience Fragment but see no templates available.

Root Cause: The XF template configuration path isn't allowed for the content path.

Fix:

Tools → General → Configuration Browser
→ Find your project configuration
→ Enable: Experience Fragment Templates

Also check that the template is published and that the author has the correct permissions for the template path.

Why Architects Care

Architects rarely think about Experience Fragments as reusable banners.

Instead, they think about content governance.

Without Experience Fragments:

Campaign

↓

50 Pages

↓

50 Manual Updates

With Experience Fragments:

Campaign XF

↓

50 Pages

↓

1 Update

The bigger the website becomes, the greater the benefit.

Experience Fragments reduce duplication, simplify campaign management, and allow marketing teams to reuse approved content consistently across multiple channels.

This is why large enterprise implementations rely heavily on Experience Fragments for promotional content, global footers, legal notices, and reusable campaign sections.

Summary

Experience Fragments solve a real problem: reusable designed experiences that need to appear consistently across pages and channels.

The key things to remember:

1. XFs have layout, Content Fragments don't — This is the fundamental difference. When you need components, drag-and-drop authoring, and visual design, use XFs.

2. Variations enable multi-channel from one source — One XF, multiple channel outputs. This is the efficiency gain that justifies the setup effort.

3. XFs update everywhere on publish — This is their biggest strength. One update touches every page that references the fragment.

4. Templates control quality — Invest time in good XF templates. They're what prevent authors from building broken email fragments or invalid AMP content.

5. XFs are not a replacement for component reuse — If you're creating an XF for something that's genuinely a component (like a card or a button), you're overengineering it. XFs shine for content-driven, editorial blocks.

What's Next

• Chapter 16: Content Modeling Best Practices — How to design both CF and XF models that scale
• Chapter 17: MSM (Multi Site Manager) — Managing content across multiple sites and languages