The Difference Between Tridion Designs and Tridion Settings

After seeing this pattern at least three times I figured it's worth explaining here (and to remind myself to note these terms in future documentation).

Your SDL Tridion design describes the relationships between your building blocks but not exactly how you build or configure them.

Technically, the implementation details and settings are somewhat out-of-scope in a functional or system design. For example a UML class diagram typically doesn't include instructions on how to create the classes or use the objects in a given language or IDE. However, for software like Tridion, it's worth adding a hint or maybe referencing the documentation.

Relationships

See how these descriptions translate into relationships in your mind:

• The empty parent publication gives you the ability to add publications later...
• The 020 Content Publication has language-specific children publications....
• These source publications have the following target publications for managed translation...
• By setting scope setting in subgroups, which belong to parent groups for rights, you can simplify the number of authorization settings you have to manage...
• A container component will embed linked components.

Conceptual Relationships and Design Conventions

These relationships combined with the typical diagrams we include in Tridion designs give us concepts such as:

• Parent and Children Publication
• Groups and Subgroups
• Source and Target Publications
• Linked Components and their Containers

You might expect to find a "parent" or "subgroup" option or setting in the system. However, except for sources and targets, these are mostly adjectives (or design conventions, if you will) used to help describe how publications, groups, or components are related.

Although you can see Members in a given Group's settings, you actually configure the Member of settings for a given Group. In other words you choose parent Groups, not children. You set the parent Publication, not children.

Settings

Though these design conventions may help explain how publications, groups, and components relate to each other, they don't explain how to set them. So if you ever find you can not set what the Functional Design suggests, make sure you have the other part of the above pairs. Specifically:

• To make a "child" Publication, you first need a "parent" Publication. Then you make the relationship in the child publication as you're creating it. This is what the empty parent publication is for since you can only add child publications to an existing BluePrint branch.
• To make a "subgroup" you first need the "parent" group. Then you make the relationship in the subgroup.
• To make a translation target, you first need at least one source. Then you make the source setting in the translation target publication.
• To be able to setup a "container" to linked Components, you first need to have a schema for the linked components, which you then reference in the Container's schema. Then with actual content you first need to have a the soon-to-be "embedded" component before using it in the container component (but there's a shortcut if you forget to make the component first)

Hopefully this makes the dependencies clearer. If you're feeling especially confident, revisit the other Tridion dependencies as described in SDL Tridion Bottom-Up or Top-Down.