I want to know best practice for where to create schemas in multibrand blueprint. In our project, we have two brands for which we need to create schema. In current blue print design, there is only one publication defined for Schemas and then we have Global Content and Design Publications for common content for both Brands and then separate Content and design Publications for each Brand.

I think we should be having two separate Publications for Schema for both brands and one publication for global schema which will be used in both brands.

So I have couple of questions:

Please confirm from your side if above thinking is correct or not. Also please confirm on best practice for where to create Schemas.

5 Answers 5


When you are talking about best practice in the WCM space it is very vague as this entirely depends on the Business Context and End User experience. Also, above what you are saying may be correct depending on the actual requirements or it may be an overkill.

You need to consider following points:

  1. Do you have schema which are common to all or majority of your brands? If yes, keep them in at the global level
  2. Do you have only very few schema which are unique to a specific brand? If yes, having brand specific schema publication will be over kill
  3. Do you have specific requirement where you do not want to show schema specific to a brand to another brand? If Yes, you are not left with a option but have brand specific schema publication
  4. Do you have specific requirement where you want to utilize Experience Manager for layout changes and want to give End User a seamless experience, I would advise to use brand specific schema publication

These are only few of the points, but may be good in giving you the direction as where you should be thinking and taking decisions.

Normally, if it is you (Developer) or the Technical person doing most of the content entry, it will be ok to keep a single Global Schema Publication rather having Brand Specific schema publications.


After a lots of discussion post this question I have written a blog regarding this: ContentModelingSchemaCreationAndBestPracticesInSdlTridion

I hope it helps

  • +1, BluePrinting best practices come from business requirements. For #3, permissions can handle the separation as Nuno describes. And #4 doesn't need much more than Page Types, Content Types, and authorization for a better experience. Authors won't see schemas in Experience Manager, but rather prototyped content and pre-configured Component Presentations. They may see additional templates, but permissions and brand-specific Publications for templates would help there. Jun 23, 2014 at 6:47
  • regarding #4, I was intended to showcase the Layout change feature through XPM and plus there may be a requirement where for a specific content type, the user want to see all possible templates that can be applied to it...no more than that; no less than that...By saying that, they do not want to have Additional Templates in it. Jun 23, 2014 at 8:28
  • Fair enough. But since the rest of the interface hides schemas and templates authors don't have access to, we could interpret extra templates visible in XPM as an "issue." :-O Jun 30, 2014 at 12:05

I always placed them at the top of the Blueprint and then used security to ensure schemas were used in the right place by the right people. It always seems to pay off compared to having to "move up" schemas later when other departments/brands wanted to use them too.

  • I agree to your suggestion, the only problem I faced is that a System Administrator for a Brand want to see specific schema for their brand only..and it took me massive amount to time to convince them Jun 23, 2014 at 8:30

BluePrinting best practices suggest separate items for different parts of the CMS. As definitions for content rather than the content itself, I've always suggested a single Schemas publication to start with.

Separate Brand-specific schemas isn't necessarily bad. It creates a strongr separation between brands and possibly less authorization work, with the following costs:

  • Duplicate, un-managed Schema copies. "Brand" may relate to design and layout more than functionality. Brand owners may (will) ask for the same functionality (often driven by Schemas) as other brands in the same organization. To comply means duplicating schemas or moving items up a BluePrint.
  • Loss of design flexibility. Brand-specific schemas means you can't re-use design as easily. So Brand A Articles could never use Brand B's Article Template or even the Global Article Template.
  • Finding them. In large setups, an annoying challenge is simply finding items, including Schemas. My best recommendation is to avoid focusing on the ideal place to put something, but rather where can you find it later? Where might you need something later?

I've seen too many implementations add something "just in case" or to meet perceived technical constraints. You can always design for a Brand-specific schema scenario without implementing it right away.

So design for today, but account for the future and how the BluePrint might evolve. Otherwise, add brand-specific Schemas as needed when the above trade-offs are okay.


The most important factor in BluePrinting schemas in this kind of scenario is who is doing the development. If you are supporting multiple brands, do you also have several development teams rolling out independent releases per brand? Do they have independent release schedules? If so, then it makes no sense whatsoever for them to share schemas.

In any case, re-use is over-rated. Is the content truly shared between the brands? This is only very rarely the case, and then when the two brands are really managed by the same team.

Did I mention that re-use is over-rated? It's just another name for our old enemy: dependency.

  • Where "brand" equals different development groups, I would agree re-use is over-rated, especially for content. As a counter example for schemas, though, I'd bet most of the Tridion blogging community uses Blogger, followed by WordPress, then whatever powers dominic.cronin.nl. :-) No re-use between the blogs except for the occasional image or snippet but the content "definition" for blog post is roughly the same between systems. Jun 24, 2014 at 21:41

Pankaj, in most of the large Multi-Brand scenarios, there needs to be two repository (publication precisely) for every thing as mentioned below (may it be schema, components etc.) :

  1. Global/master level containing items available across the brands
  2. Brand level containing items available at the brand specific level.

Hence, there should be one Global/Master schema defined at level 01 as master schema under 00 Scalability layer which should be available for all brands. And each brand should have separate schema masters Level 02 that would contain schema only applicable to that particular brand.

But as Pankaj Gaur rightly indicated, since content is mostly uploaded by technical guys like us (ironically), people prefer to put all schemas in just layer 01 Master schema.

Hope this answers your question :)

  • Further, again this is dominate by the actual Business Requirements Jun 23, 2014 at 4:24
  • You may want to see this post of mine on best practice regarding schema creation Jun 24, 2014 at 15:31

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.