Blueprinting is very useful and powerful, but it is too powerful sometimes. It is actually hard to not inherit (or blueprint) something. For example, we are selling different products for different countries. We really don't want certain products to show up in certain countries. It seems there is no simple way to achieve this. Our solution is to use some metadata to control whether the product is needed for the country. If it is not, the publising will fail. It is more like a workaround then a nice solution. I would like to know how this situation is handled in other companies.

  • 3
    Blueprinting cannot be "turned off". We've looked at this in the past, and we still consider enabling it in a future version, but not before we work out the complexity of this (like making it understandable that something is not inherited).
    – Nuno Linhares
    Commented Aug 19, 2015 at 6:27

4 Answers 4


In conjunction with BluePrinting, use Folder level security and share only the content that each Group needs to see.

  • What if there are in the same folder? We are organizing the product per category and the same category of products are in the same folder.
    – charles
    Commented Aug 19, 2015 at 16:27
  • Then localize the folder and change permissions lower in the BP, or have use a different set of content, e.g. common shared, shared for localization, and local non-shared. Commented Aug 19, 2015 at 17:45
  • I am talking about Structure Groups, all the pages are in the same Structure Group. We can have component in different folders, but that will not help with pages. Basically, we have one product page which is going to certain countries but not others.
    – charles
    Commented Aug 19, 2015 at 20:35
  • As Nuno mentioned, you can't do selective inheritance via BP. I'm just trying to provide options for you :) You'd have to use different SGs or possibly add a TBB to your PTs to throw an exception based on some logic that checks who can and can't publish certain pages. A GUI extension can also be developed to "hide" inheritance. Commented Aug 19, 2015 at 20:58

For a product management use case where you only have Tridion I'd definitely start with metadata to manage which countries/channels/customer segments get which products.

However, I wouldn't recommend publishing failures to control what gets published where. Consider three possibly better fits for the use case:

  • Publish mostly through Bundles--each bundle contains only the items you want for each country
  • Control what gets published (or not) via custom resolving -- you won't have failures since you'd only publish what's "allowed" for a given Publication or country.
  • Resolve what appears in delivery -- publish everything, but use the CD API to control what displays. This would be a good fit when displaying products dynamically.

Beyond this I'd also consider SmartTarget and other "personalization" tools to handle variations in sets of product and their order.


@charles - Tridion is content management tool, I would highly discourage the use of Content management tool for product management because that is not what it is meant for.

The way you handle the situation is, have a separate product management tool where you can handle all the attributes for product and in your content management when you create component you can add attributes and based on which at run-time you can retrieve the product information product management tool and display.

  • That would be ideal, but we don't have a product management tool at this moment so those two are all in tridion. If it has to be inside tridion, I am interested to learn where here is a better solution.
    – charles
    Commented Aug 19, 2015 at 6:27

You can make pages in a structuregroup non-publishable. In a child publication where you do not want to have certain products you can localize the SG and set it's unpublishable flag.

I would prefer this solution over throwing errors on publish as this could have unintentional consequences (you don't want publishing to fail; you just want certain pages to not be published).

If you want to use Tridion to manage shared-but-not-always-used items I would suggest creating a custom page which gives you an overview of which product SGs are enabled/disabled in which child publications (as I would expect this overview will be very frequently requested by product managers).

A limitation of this approach is obviously that you'll have to group products into SGs as you cannot disable a single page from being publishable (only a feature on SGs) so if you want to control it per product you need to create a separate SG for each.

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.