an abstract image of a grid adhering to waves with various spotlights of teal and purple

Best Practices for Sitecore Architecture and DMS Scalability

Toby Gutierrez
Toby Gutierrez

Keeping stakeholder’s future business goals in mind and letting Sitecore best practices guide you will ensure a scalable website and win-win each time.

First and foremost, there are many ways to architect a website solution in Sitecore. That is easily one of the greatest things about using the Sitecore Content Management System (CMS) – anything is possible. With that being said, in this post we will discuss some best practices for Sitecore architecture (regardless of whether the client has a license for Sitecore Digital Marketing System (DMS) or not).
Setting up the architecture and code to handle multiple sites, personalization, AB and multi-variant testing is very important. Why? Stakeholders can change their minds often – so count on it and be prepared for it. Oftentimes even when they say they don’t want or need DMS now, chances are they will probably want it later. If that’s the case, there may be an effort later to implement DMS depending on the how the site and code solution was originally architected. Some great advice I have always adhered to in web development is that scalability and extensibility should not be sacrificed in the project at the expense of just simply turning out a project as quick as possible to meet deadlines. By setting up the architecture up front to account for the DMS is a win-win for the stakeholders and us as developers. It builds trust and respect when we can tell the stakeholders that the website they invested in is a multi-site and DMS friendly even though they don’t have a need for those features now. The tutorial below will show a basic example of setting up a site from scratch that is multi-site friendly and DMS ready in Sitecore.

In the example below, the end result is going to be setting up the home page with 3 callouts that are calls to action (CTA) that compel the visitor to convert based on how many times they have visited the website.

I will start off first by creating the template architecture below:

Template Architecture

  • The base folder holds the base templates meant to be inherited from by the other templates. The base inherits from the standard template and all other base templates inherit from base.
  • In the site folder I created a site template for the different sites. I also have a site components folder template, which is used to contain the site components, for the different sites as well.
  • In the callouts folder I created callout templates (image, text or video) and their respective folders that have insert options set to insert only the respective callout into the respective folder (image, text or video).
  • In the globals folder I created a components folder template, which is used to contain the global components, which are the items to be used for DMS personalization, AB and multi-variant testing.
  • In the pages folder I created the home page template and a content page template for the other pages in the site.

After the templates are in place, I can create the standard values for the templates and set the insert options on all the templates standard values.

Next, keeping scalability in mind, I am going to create a branch for the site template. This way anytime the site template branch is inserted as a child of the content item, it will also bring with it a small sub-site with a home, about us, contact us and privacy page. As the architect I know that in the basic example below you will find 3 different sites. All 3 sites have the same design with just CSS and image differences, however the HTML and functionality across these sites generally remains consistent. With that in mind, below is the branch I created with the site template:

Site Branch

Now that I have my templates, insert options and branch in place for this basic example, I can create the content tree as seen below:

Content Structure

In the example above, I created 3 sites by inserting the site branch template. Then I created a global components folder item and site components folder in the content root. The global components are components that can be used by all 3 sites whereas the site components are specific to the sites themselves. A great way to manage global components is by using cloning. You can create a component in the global components folder, clone it to the sites you want in the sites components folder, and when you modify the global component item, it will modify the components in the other sites.  However, that is out of scope on this post so that’s as far as I will go on the topic of Sitecore cloning.

Let’s focus now on the site components folder where I created some components. I created a site A folder (based on the site components folder template), which has a home folder (based on the container folder template) that contains the callouts that I need for personalization on the home page. In my example, the home page for the website site A has 3 image callouts, 2 text callouts and 2 video callouts ready for use as components by DMS.

You may be asking yourself, why keep the global and site components outside the site as siblings of the sites rather than have them inside the site as a sibling of the home item? Here are a few reasons:

  1. You should develop with the content editors as being your key end users of the Sitecore product. They will be mostly the ones inside the CMS and it needs to be as simplistic and easy to understand for them as possible. In my experience, I have found that when you clutter up the content tree with anything other than pages then it can confuse content editors and lead to frustration. In addition, it’s easier for future Sitecore developers to understand and ramp up on the architecture when the architecture is set up this way. Following paths from the URL to items is very easy and then you can drill down into presentation details and data sources from there. In essence, unless absolutely necessary, keep the content tree for the site free of data source items and place them as siblings to the home item is my recommendation. This keeps the content tree clean.
  2. Another reason is for hierarchical and programming purposes. In the event I need to programmatically grab the children of any page and present a hierarchical representation of the structure, then I will have to account for skipping the components folder or data source folders. As an example, let’s say I decided to put the components folder as a child of every page so I know what components go with that page. That’s one way to do it but it clutters up the content tree and now you must account for skipping the components folder in code for a hierarchical representation (e.g. navigation, articles, etc). Sitemaps also will need to skip this folder as well if you build a sitemap crawler to run through your content tree and build out a sitemap. Again, this is a matter of opinion and something to account for in code.
  3. The third reason is with this approach you can point the data source location field in the sublayout all to one folder and then adjust content editor permissions for that content editor to be able to read/write on their respective site they are editing so the editor only sees the components for their site. So if I were a content editor for site A, I would only see components for site A not B or C.  See below that I set data source location to site components and the template to image callout for the image callout sublayout.

Data source Information in Sublayout

By setting the data source template to the image callout this ensures that only this template can be chosen as a data source in the sublayout in the presentation details of the item.

 Callout Sublayouts

Now we can set the presentation details of the page for the home item for site A as seen below:

Presentation Details for Site A Home Item

Now we can personalize the image callout that is a call to action to see what variation of title, text and image is compelling the user to click on the callout. I selected the image callout and pressed the personalize button in the above image. I am presented with the “Personalize the Component” dialog box where I can add/modify/remove conditions for my testing.

Personalize the Component Dialog Box Blank

I want to select the default component to render so I click on the personalize component drop-down and get the “Select the Associated Content” dialog box below:

Select the Associated Content Dialog Box

Keep in mind I see all 3 sites because I am an admin but if you setup your content editor with access rights to only site A they will only see site A.

Since we set the data source location to this folder in the image callout sublayout it pulls up the folder and children. Notice how at the bottom there is a warning. This is because the site components folder item is chosen when the dialog box opens up by default. Since we set the data source template to image callout template, the dialog box will not let you select any item based on a template other than image callout.  This is some great validation Sitecore built in to the DMS that we can take advantage of.

I selected the CTA image one callout as my default component and now I’m back at the “Personalize the Component” dialog box as seen below:

Personalize the Component Dialog Box with Default

If we were to publish now, when the page renders the default component that would render would be the CTA image one callout. However, we want to test out the 2 other CTA image callouts to see what works best in converting visitors so I click on new condition in the upper right hand area of the dialog box. Now I give my condition a name of 2nd visit and select CTA image two callout doing the same process as mentioned before to select CTA image one callout. In this case, if this is the visitors 2nd visit I want to present a different CTA image callout than a first-time visitor. To do this, I select the edit button where I get the “Rule Set Editor” dialog box where I set the rule to where the visit no. is equal to 2 as seen below:

Rule Set Editor

As you can see there are many rules for personalizing the components. You should become familiar with them just for knowledge and understanding of the possibilities for DMS personalization. You can also create your own rules as well.

Lastly, I add a third component in case the visitor visits a 3rd time. If that is the case, then I want to present a different CTA so they will be compelled to convert or tell friends. When I get done setting up my personalization scenario for the different components, my image callout sublayout looks different in the presentation details. The image callout now has 3 on the icon representing the number of variations that the component has as seen below:

Personalize the Component Dialog Box with 3 Conditions

When published our personalization scenario will be in effect.

In code we simply need to check for the data source in the image callout sublayout on page load.  If populated, it will render the appropriate component based our conditions. A best practice for getting the data source of the sublayout is to inherit from a base sublayout class. It’s a few lines of code to retrieve the data source, but since there may be many sublayouts using that code it just makes sense to inherit from a base sublayout class for productivity and code reuse. Click here for a generic BaseSublayout class that can be used to get the datasource of an item.

In this example, we have seen that it’s just a minor change in architecture philosophy that can make all the difference for Sitecore clients.  It’s the same amount of effort – if not less – to build a website in this fashion and a win-win all around.

Let's Get Started

We'd love to hear from you. We probably have a lot in common. I mean, you like chatting about data-binding, UX patterns, and javascript functions, right?


Cookies help us improve your website experience. By using our website, you agree to our use of cookies and our privacy policy.