Is it possible within Tridion 2013 SP1 to have an embedded schema field that allows more than one type of embedded schema. I was wondering if anyone has tried this using a complex schema or knows of any other ways this could be achieved. I would like to achieve the following:

Schema A (Embedded Schema)   
Schema B (Embedded Schema)
Main Schema (Component Schema)
     - >Field A (title)
     - >Field B (Embedded Schema Field Allowed Schema's (Schema A, Schema B))

I know I could achieve something like this with a component link field but that isn't very elegant in terms of a content editor. Any help or advice would be much appreciated on either achieving this, complex schema's or examples of something else that may work. Even if the advice is to tell me this is not possible.

Many thanks


Thanks for your responses guys. I thought this was the case but thought I'd ask. The reason, as Rob has mentioned, was for user experience. I figured I would either have to go down a GUI extension or component links route but good to hear it from other people before I decide on an approach.


  • What type of content is this for? I normally do not recommend Component Links as the first option to model content with similar fields, but I'll post an answer. Commented Mar 9, 2015 at 21:36

3 Answers 3


Not as far as I know but I guess one approach would be to add all the fields to a single embedded schema and then instruct users to use the correct fields based on the type - the type being determined by a drop down field.

You could take it one step further with a GUI extension to hide the fields based on a naming convention e.g. if the value of the first field was "event" only show fields which are prefixed with event_ or something.

However, I'd recommend Component Links unless your real value is the improved user experience of not having to create lots of components to create one thing on the page (which is what I'm guessing you're going for).

You could even write a GUI extension that created Components in the background and bought the fields from the selected schema into the same window but there would be lots of things to think about and it would probably fairly involved to write.

  • I can only mark one of these as a answer but both were great and very helpful. I have marked both answers up and marked one as the solution but if I could do both then I would. I have mark Rob' as the answer for the GUI extension as it targets my wanting to give a good user experience.
    – mackie1908
    Commented Mar 9, 2015 at 20:21

As far as I know, there is no provision to allow more than one schema type on Embedded Schema Field.

But I think you can try this by modifying the source of the schema (I haven't tried this option yet).

By the way, it's not a good approach.

From my experience, I would suggest to have Component Link field which allows more than one schema type.

Advantage is, you can reuse the content and translation will be limited (Hence, Less cost is involved). If you opt with Embedded schema, you need to send same content for translation couple of times and which costs high.


Show / hide logic in Tridion Schemas?

A text fields that uses a Category (with nested Keywords presented with the Tree option) is probably the closest thing we have in Tridion that presents additional options after a user selects an initial option. But this only works for selections.

Separate Schemas Rather than Component Links

For two Schemas with different fields, but a common Title or Heading, I'd recommend separate Schemas rather than a GUI extension or Component links as seen below:

Main Schema A (Component Schema)
     - >Field A (title)
     - >Field B (Embedded Schema A)

Main Schema B (Component Schema)
     - >Field A (title)
     - >Field B (Embedded Schema B)

If the title, A, or B were usable or presentable on their own I might suggest three Schemas, especially if using Experience Manager, SDL Mobile, and/or SmartTarget.

I point out when near duplicate schemas make sense in this post.

Advantages of separate Schemas (not Component links) include permissions control and the ability to set a default set of fields (linked Schema as a default) for a given folder. Having them separate also simplifies template development and dynamic functionality (query by Schema rather than if/else logic in templates).

Recommendations if you separate Schemas:

  • If they're related, use a naming convention that places the two Schema next to each other in the drop-down list (e.g. Article Press Release and Article Blog)
  • Optionally use the same field names, to simplify template development
  • However, use specific field descriptions (see tips in this post)

Extension Recommendation

If you do Component links, be sure to restrict the options to only the right Schema.

For a GUI extension or automation with the Event System, I'd look at the entire editorial process, including Experience Manager (XPM). For a given task in terms of creation, updates, and re-use (read that as a variation on CRUD), I'd look to optimize the most tedious parts for editors.

For example, even with a Component that had all the fields, if using XPM Page Types or Content Types, creation is optimized since editors don't need to fill out all the fields. However, edits and re-use might be harder because you have more fields in fewer Schemas.

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.