Using inheritance for XF patterns

[nataliecb]

We'd like to build common layout patterns as experience fragments so that an author can drop in a pattern and then break the connection to the XF so that they can directly edit the content on the page. For example, a pattern of heading + 3-columns + cards in each column, or a pattern for a campaign page using an image hero, HTML block, text, icon tiles for unique selling points. 

We want to do this in order to avoid having to build multiple different templates - that wouldn't give us the flexibility we're looking for as then we have to maintain multiple templates unnecessarily. 

However, I can't see an option to break the connection to the original XF (eg with an inheritance chain disconnection). I thought this existed but is this only when creating launches?

Keen to know if anyone has ideas about how to achieve what I am trying to do. 

[giuseppebag]

hi @nataliecb,

It sounds like you’re trying to use Experience Fragments (XFs) more like reusable layout blocks that authors can “instantiate” and then fully customize per page. Out of the box, AEM doesn’t offer a “break XF inheritance” feature in the same way that you can break inheritance for page components in Live Copy or Launches. XFs are designed to stay in sync with their source unless you actually duplicate them into a separate XF asset.

If your main goal is to provide flexible, repeatable layouts without having to create and maintain multiple page templates, you might want to look at a couple of AEM-friendly options:

1. Core Components + Policies

   • Build your patterns as component groups that authors can assemble directly on a page using the Layout Container.

   • Use the template editor to allow the right components in the right drop zones, so authors can build “heading + 3 columns + cards” without needing a separate template.

2. Page-level component variations (“pattern components”)

   • Create components preconfigured with a given layout (e.g., hero + HTML block + USP tiles), but allow them to be edited freely once placed on a page.

3. Content Fragments for text/media, Style System for layout

   • If part of the need is for content reuse but with layout flexibility, separating content from structure can give authors more control.

Inheritance-breaking for XFs isn’t a built-in feature like it is for Live Copies, so if “drop in and then edit” is the main need, a component-based approach with well-defined templates/policies is often more sustainable than using XFs as layout patterns.

[nataliecb]

Thank you, @giuseppebag , our goal is indeed to provide repeatable but flexible layouts without maintaining multiple templates. 

We have avoided putting too many parameters around dropzones in order to maximise flexibility so at the moment, an author can create any layout they would like, but this means they always have to do this from scratch. We could provide this as Initial content but then they have to delete items they don't want to use. 

Can you explain to me more about the Page-level component variations and how you would set this up? This approach sounds appealing but does this mean we would then need to maintain this as a separate component?

[kautuk_sahni]

@nataliecb just checking in! Were you able to get this resolved? If one of the replies above helped—whether it completely solved the issue or simply pointed you in the right direction—marking it as accepted can make it much easier for others with the same question to find a solution. And if you found a different way to fix it, sharing your approach would be a great contribution to the community. Your follow-up not only helps close the loop but also ensures others benefit from your experience. Thanks so much for being part of the conversation!

[nataliecb]

Thanks @kautuk_sahni , I can say the above answer did confirm the inheritance option I was looking for was not the solution available. I have not been able to find a satisfactory solution unfortunately. 

• Drop zones are not what I need as we have already got very open and flexible templates.
• Pre-configuring components into layouts IS what I need but I don't want to create these as a new component to sit in the sidekick, which I think is what is being suggested?
• Content fragments are not what I need either. 

The first reply helped confirm what isn't possible but hasn't helped me find a solution (yet).