Some time ago my team and I decided to break out some often-used fields into components that can be inherited, a Heading field being one of them. We put the Heading field into it's own template and started using it as one of the base templates for other templates.

As we started using this component we discovered that when you have more than one component on the same page that uses it, the value of one of the Heading fields will be shared across all instances of that field on that page. My question is: Is there a way to make inherited fields unique to the parent item that uses it? Or are we just doing it wrong?

2 Answers 2


A solid option is to build components that have a data source item rather than relying purely on fields defined on the page.

Here's a scenario to help explain what I mean:

Let's say you need to render a hero on the page, along with a few promotional items. I would imagine that the hero image is defined on the page, since many of those page types could use a hero. We add a Page Content component to render Content text and the Hero image.

enter image description here

I could add more fields to the page template, but why not have the component reference a data source designed specifically for what's need? So after some more development, improved styles... you add new components with data sources. We add two Promo components configured with local or global data sources.

enter image description here

Note: This was demoed with SXA. I encourage you to give that product a spin to see just how simple this can be.


As Michael mentions, you are doing it wrong. You have a page item that has fields on it, and then building components that pull fields from the current context item. As Michael noted, you should always build components that are reusable with a data source (with fields) that are contained within another item. That way if you want to add 50 headline components to a page, you don't run into a scenario where you can't because you need to add another headline to your page template.

Having said all that, there is a way you can get around that. It's bad practice, and I highly recommend that you do not follow this. You could create on your headline component a rendering parameter. This rendering parameter would include the name of the field to pull from. Example, if you had on your context item 5 headline fields, such as (headline 1, headline 2, etc), you could specify in the rendering parameters that this component will pull in the value headline 1. Then on the second headline component on that same page, you could set the rendering parameters to pull from headline 2. This would also allow you to get around the issue of building 5 headline components for a page.

But like I said, this is a bad practice.

  • 1
    Good example at a bad practice :) Sep 15, 2018 at 2:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.