Some Tridion implementations I have worked on/designed make use of just a few schemas and tend to use a General Schema which has a lot of Component Templates linked to it. The Component Templates do not generally make use of all the fields on the schema and often none are mandatory.

What are the advantages and disadvantages of this approach?

It seems to me it makes the solution flexible but at the cost of some editor usability. It would be interesting to hear others' thoughts on this.

  • 4
    A little background about this: Having a "General Schema" comes from a time where it was good practice to have as few schemas as possible. Back in the days where we still use VBscript/XSLT templates (not the compound type) it was generally easier to reuse code when you had just a couple of schema's and code TBBs. On top of that it also gave less errors when you previewed or published your pages. Now, APIs and tooling have improved and it makes more sense to create schemas for different types of content. Easier for filtering and easier for content editors to work with
    – Kah Tang
    Commented Mar 12, 2013 at 22:29

11 Answers 11


A generic content schema can complement a well-designed content model, but shouldn't be the only schema in an implementation.


A generic schema offers:

  • Familiar and consistent fields for authors and template designers
  • The ability to create a variety of component presentations (ultimate flexibility has a cost, though)
  • Faster development; existing templates can be used as examples and TBBs may be reused.

The generic approach assumes page = rich text format area, which doesn't fit most organizations' content types nor takes advantage of the separation of structure, design, and content.


A generic schema can add user add technical debt, as Jonathan suggests, and has the following disadvantages:

  • Tendency to grow such a schema to accommodate a variety of scenarios (as Puntero describes)
  • Large numbers of component templates for a given schema which is bad for authors, but also impacts development
  • Lack of control over permissions (specifically because we can't hide sets of schemas in folders) but also the inability of restrict a set of component templates to a content type and its specific schema
  • Descriptions become less helpful since re-used fields apply to many scenarios

An author's experience with a given content type as a decision tree of sorts. Reducing these options will improve efficiency as well as "trust" in the system--each field is clear and choices have an obvious affect on the site.

Recommendations and Observations

Rather than assuming a generic schema, considering the following approaches.

  • Use Embedded Schemas. Use structured sets of fields with embedded schemas You'll typically see this approach with the "Paragraph" embedded schema
  • Group Editorial Schemas. In your designs (and even folders), you can definitely group schemas into "types." Rather than a single Generic schema, a section for Editorial schema can help organize similar, yet distinct schemas and the content types they implement.
  • Make the Schema-Template relationships Visual. A schema-to-template mapping, either as a diagram or in table format, can help show issues with a content model and how a generic schema and its templates would be problematic.
  • Limit Author Selections.

I've joked that a CMS with a single schema and template would be a blog. Speaking of which, I'd encourage other answerers to join the discussion around Tridion schemas and content modeling through their own blog posts or in comments to existing posts.


Reusability is good, but if you have different types of content, it can be an error trying to fit all of them on the same schema. The most affected by these decisions will be the editors, it is good to check with them how they envision the content model.


  • Reusability. You can reuse the same content with different presentations avoiding repeated content.

  • Easier for the editors to select the appropiate schema. (This could otherwise be mitigated with default schema per folder)


  • Dead Fields in some Presentations: Some templates will use certain fields, and other templates will user others. The used fields are easier too remember when you have a couple of CT (i.e: summary and detail), but when you go overboard this can lead to:

    • Confusion on the editors "Why is this field not displayed?", "What field should I fill in?"
    • Lack of context. Omiting certain fields can lead to loss of critical information.
  • Difficulties selecting the correct CT. The editors need to be trained to understand which one of the XX CT corresponds to the presentation the he is looking for. (And what fields will be displayed)

  • Reduced control over permissions.

  • The need for new fields is not uncommon. The more content types you fit into the same schema, the more likely you are to add new fields to an already too big schema


Having a single 'General Content' Schema seems to work quite well for content that is actually normal 'marketing' content. However, if you have a lot of fields that are consistently not used, except for in specific circumstances, then this would suggest that you may want a new Schema for this type.

Although keeping the number of Schemas down is important from a maintenance and purists perspective, it is more important that content editors can use Tridion as easily as possible. They will be spending possibly hundreds of hours editing content in Tridion, so it is important to make their lives as easy as possible.

(Obviously you would want to keep common field (XML) names the same between Schemas.)


Additionally to what Angel stated, if it is a Content Type (Contact, News, Article, Product, Service, Card etc...) DO NOT USE a General Content schema. Instead just create a specific schema for that content type, yes... they might have the same field but that is not enough to actually group them together. In case you find it convenient just create an embedded schema to put together those common fields in both (regular) schemas.

There is somthing which is overlooked quite frequently nowadays and it is very surprising to me... PERSONALIZATION. We are moving into an internet which is much more personalized, how are you going to target a visitor with X content type (product, banner, offer, travel) if it is general content??

  • Good point about personalisation using the Schema type to load in specific types of Content. Commented Mar 12, 2013 at 18:57
  • 2
    Do keep in mind that Xperience Manager does not like Embeddable Schema's very much.
    – MDa
    Commented Mar 12, 2013 at 20:56
  • +1, especially since it's fairly easy to filter/restrict/query by schemas across the various APIs. Well, you could add a checkbox for "Content Type" (that's a joke, no don't do this). Commented Mar 13, 2013 at 21:53
  • 1
    I believe MDa's referring to the inability to add an additional set of embedded schema fields from the inline editing UI. Experience Manager's strongest features, IMO, are providing context to authors and the ability to interact with content types (component presentations) visually. Authors still need to occasionally open components in form view and/or author complex components in the CME. Wanting to use Experience Manager shouldn't prevent implementation from considering embedded schemas. Commented Mar 13, 2013 at 21:58

Great question, and lots of good answers already here so I will not repeat their content in my answer. No-one seems to have mentioned Workflow yet. If you are, or may in the future implement workflow for particular types of content, then it is much better to have separate schemas, as the workflow definition is (at least for version 2011 and earlier) related to the schema. If you have a General Content schema then you cannot have different workflows for different types of content, and more importantly cannot turn workflow on and off for different types of content - its all or nothing!

More reading on schema design can be found here

  • Permissions, delivery-side queries, author-friendliness, and workflow... all based on a content definitions, aka schemas. Maybe the generic answer to the generic schema is, "why wouldn't you want to define your content?" Commented Mar 13, 2013 at 22:13

A fine balance needs to be found between using a massive "all-in-one" schema or specific schemas. The general rule is to reduce the amount of schemas and templates to avoid duplication and promote re-use. But this can quickly get out of hand as well. So in my opinion, use common sense and work with the client to design what works for them.

Alvin discusses this exact topic in his excellent post "10 Extreme Schema Scenarios": http://www.createandbreak.net/2012/01/10-extreme-schema-scenarios.html

And here is another related post: http://www.createandbreak.net/2012/12/when-near-duplicate-sdl-tridion-schemas.html


I think all in one schemas are a disaster waiting to happen if you have any remote need to port content later. In a traditional templating setup, if you don't keep tabs on where CTs or PTs are using the fields then you have an awful lot of regression testing to do whenever you introduce changes.

I prefer to try and stick to one schema per content type. Tridion is a CMS so editors should come first. With the advent of DD4T it's straightforward anyway from a templating POV for developers!

  • +1, especially to the point of keeping track of how fields are used. Not sure how many times someone asked, "what does this field do?" and the answer was, "ummm... don't know." Commented Mar 13, 2013 at 22:10

In my opinion, General Schemas work ok, but when you get to the point when adding new editable content to a CT and someone says, "Just use the x field and we'll document how it works" you need to create a new schema.

It's common sense, use it where possible, but don't force nonsensical content into fields just to use the general schema.


In software development generally, the search for re-use has always had to be tempered by the fact that re-use has a dark side. To achieve re-usability, you first have to manage our ancient enemy: dependency. Nowhere is this more apparent than in the relationship between schemas and templates.

The only reason for having several templates related to a schema should be that you genuinely wish to have multiple views of the same data. What's more - all of the templates related to a given schema need to be controlled by the same programmer/team. The schema is then "owned" by that team, who may change it as they wish over time, assuming that they are prepared to manage the changes.

If you have a General schema, any time you wish to enhance a specific feature set, you'll have to assess the impact on, and re-test all your other feature sets, and that's assuming that you don't find yourself so thoroughly painted into a corner that the desired change is impossible without a major re-write.

Even if we were to accept that some benefits of re-use might come from having a General schema, it's not really that likely to help the content workers. If you have a schema with lots of optional fields, some of which are needed in one scenario, and others in another, you have already lost the game. Imagine the training overhead you are inflicting on that team, not to mention the additional concentration they will require every day to do their job effectively. For a lot of less common tasks, they'll have to revisit your (inaccurate?) documentation every time.


You may also wish to consider if you have any dymanic content. For example we have news articles which are regularily updated and which appear across our sites and we often need to show the most recent articles on a number of pages without the need for editors to update each page. For this we dynamically query the broker in our User Controls.

If you use a one size fits all approach, then when you publish the components out dynamically you will soon start to see a big load on the publisher as it has to render the component for each dyanlically linked template regardless of whether it's needed or not.

In the dynamic world it is often better to create separate schemas and embed common fields and then you can control which CTs target which schema. Your templates can be coded to work with the common elements to ensure you don't duplicate these.


Tridion Schema's purpose is to define information and data, like database table :) so the similar question will be "a General database table for everything?" you and many people will have an easier answer for that. practice telling us, general content table exist and specific content table exist too.

i agree to Nick, according to the requirements. you may have both general content schema and specific content schema. also consider general content and specific content have opposite time cost. so for long-term, you will see a better TCO of well balanced design.

  • Welcome to Tridion Stack Exchange! Thanks for your answer, however, it does not seem to address the 'advantages and disadvantages of using a "General Content" schema' as asked by Rob. I think you are onto something with your reference to opposite time cost of for general and specific schemas, perhaps you could expand upon that? Commented Mar 13, 2013 at 5:22
  • Interesting--we do have a variation on the general database table on the delivery side with CUSTOM_META. Maybe an even more generic approach from the CMS side would be a key-value setup. Commented Mar 13, 2013 at 22:06
  • as my answer the advantages and disadvantages of using a "General Content" schema is the same as general content database table, they are both existing for different purpose or business requirements. for example: one for specific product, and another for general product, you can find may Tridion implementations has this kind of design. for one specific business requirement, you may say general content is better vs specific or not. like Car and SUV which one is better? i am not sure if i explained well? thanks
    – Lucas Liu
    Commented Mar 14, 2013 at 21:20

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.