I'm going to date myself here but I still remember being 4 and excited because on our 3 channels on the TV one was showing the original Wizard of Oz. I was always amazed when Dorothy stepped out of her house into Munchkin Land and the movie switched from black and white to Technicolor. In a similar vein, we often have features that, when deployed, alter our system drastically.

I happened to be trolling the Sitecore Slack channel where we plug our blog posts or post really good ones from others and came across Brian Pedersen's blog about LaunchDarkly. This is an API based feature flag repository rich with rules based switching logic. The purpose of this blog post is to expand on the concept of feature flags (or Toggle Switches) and provide a few different approaches with examples of why and how they fit into a solution. These approaches fit well within a Sitecore solution.


The purpose of feature flags in a solution is to provide an on/off switch for features. The idea is to be able to deploy a feature into production turned off. Flipping the switch, one can then enable the feature and if it remains stable, leave it on. In the event an unforeseen side-effect occurs, the feature can be turned back off thus restoring stability to the production system. As Brian points out in his blog post, feature flags are typically short-lived. Once a feature is stable a subsequent follow-up deployment removes the if/else gate and the feature is deploys always-on.


API Based

Using an API based approach to manage a repository of feature flags effectively separates concerns across a solution architecture. For features that are more systemic and cross channels or sub-systems, an API based approach can provide an endpoint multiple sub-systems can interrogate to enable or disable a feature. Launch Darkly, at first read, provides a very rich rules based approach to determining the on/off state of a switch. One thing to keep in mind with an API based approach is WHERE the switch is used in a Sitecore solution. For example, if one were to write a pipeline processor that fires on every request, we need to keep in mind that the cost of calling the API and receiving the response will be incurred on every request. If the API is "close" and relatively fast, we may only incur 10-20 milliseconds per request. If however, the API isn't scaled appropriately, under load we may have problems. Using an API based approach requires optimization such as caching and fault tolerance to be built into the client calling the API and potentially in the API itself to mitigate this performance risk.

Sitecore Toggle Switches (Content Based)

For pure Sitecore solutions or for feature switches that will only impact Sitecore code, another approach that is fairly easy to set up and manage is creating switches directly in Sitecore. Historically I have used a simple template that consists of Switch Name, Description and a Checkbox determining the state of the switch. My personal preference is to inject a Toggle Switch Repository into code for the purpose of getting the switch value. This allows for a little defensive programming in the case where the switch content item may not [yet] physically exist in the repository.

public interface IToggleSwitchRepository {
 bool IsSwitchEnabled(string switchName);

public class ToggleSwitchRepository : IToggleSwitchRepository
 // Glass Mapper service
 private ISitecoreService Context { get;set; }

 public ToggleSwitchRepository(ISitecoreService sitecoreService) {
 Context = sitecoreService;

 public bool IsSwitchEnabled(string switchName) {
 var switch = Context.QuerySingleItem($"/path to switches//*[@Switch Name='{switchName}']");
 if ( switch != null ) return switch.Enabled;
 return false;


Rendering Parameter Toggle Switches

A third approach to switches is solely for the purpose of managing isolated logic gates in renderings. If you're unfamiliar with rendering parameters, I wrote a post on this a couple of years ago you may find interesting. You can find it here.

This is a very narrow use case because Sitecore already offers other ways to choose one rendering over another and it really gets down to preference and correct layering of the application. As an example, we may have an experimental rendering where we want to make one service call over another to populate our model. Again, this use case is very narrow.


Toggle Switches or Feature Flags (your choice!) when used can ensure the Continuous Delivery pipeline isn't blocked when questionably stable code is introduced. There are a myriad reasons why code the works fine on a Development machine fails in Production. Instead of doing a hot fix, try a toggle switch, or a feature flag.