Master Hierarchies

The topic of creating master hierarchies (i.e. default subitems) is covered at length in the Sitecore Certified Developer 1 training and in the Sitecore Developer Cookbook: http://sdn5.sitecore.net/Developer/Developers%20Cookbook.aspx.

Master hierarchies allow business users to create entire branches of a content tree through the same process used to create a normal content item. Consider a case where product descriptions are divided into four logical subjects, displayed on separate (or the same) web pages:

I. Home
  a. Products
    i. Product A
      1. Product Features
      2. Detailed Specifications
      3. Pricing Information
      4. Order Information

Rather than having business users manually create four sub-items for every new product, developers should create master hierarchies to automatically create the child items as well as the Product itself.

There are some system-related limitations to organizing masters (under /sitecore/masters). Specifically, developers cannot organize masters into subfolders. For example, ideally your masters could be organized thus:

I. Sitecore
  a. Masters
    i. Site A
      1. Master A
      2. Master B
    ii. Site B
      1. Master A
      2. Master B

Unfortunately, this arrangement is unsupported. The reason for this is that Sitecore uses the structure of the masters themselves to determine master hierarchies. In the structure above, Sitecore assumes that Site A is a master hierarchy with child masters Master A and Master B. Sitecore will not interpret Site A and Site B as organizing items (even if, for example, they are based on the Folder template). A possible approach to organizing masters, then, may be to rely on naming conventions, such as:

I. Sitecore
  a. Masters
    i. SiteA_MasterA
    ii. SiteA_MasterB
    iii. SiteB_MasterA
    iv. SiteB_MasterB

A shortcoming – and potentially a major one – of this approach is that it produces masters with non-business-user-friendly names. In other words, when business users right-click on a content marker, they will see the site prefix on each master. This may cause confusion and require additional training. A workaround for this is to change the display name of the master and that name -- rather than the actual name of the master -- will be displayed in the UI.

Keep in mind that read permissions can be placed on masters so that users only see masters in the UI that are relevant for their content creation purposes.