Sitecore OOTB comes with tons of personalization rules that we can use, however there might be times where we need to create a custom rule condition that fits to the client business requirements.
Luckily with Sitecore framework that’s known easy to extend, we can easily achieve this.
Here’s the steps to create a custom personalization rule:
1.Register the tag
First of all we need to create a new tag item under /sitecore/system/Settings/Rules/Definitions/Tags
2. Register a new rule element
Create a new element folder in /sitecore/system/Settings/Rules/Definitions/Elements
3. Create a new personalization condition rule
Here I’m creating a new rule and calling it “Specific Template Name” which will do what exactly that, checking if the current context item is based on a specific template name – not really useful in real world scenario but this post is about how to setup a custom personalization rule 🙂
In the newly created rule we need to set the Text and Type fields
Text field contains the text that we’re going to present to the content author, here’s the following text that I use
|
1 |
where the current template name [OperatorId, StringOperator,,compares to] [Value,,,specific value] |
the [TemplateName, StringOperator,,compares to] represents the format of input that we want to get from the content author. It follows the following format
- OperatorId, defines the public property of the class where we want to assign the value coming from the content author input
- StringOperator, the built-in macro that we want to use to get the input from the user. In this case this will be a string comparation operation
- blank, this parameter will depend on the type of macro that we use, this could be a default text value if we are using the default macro, it could be a default start path if we’re using the Tree macro – think of it like setting a field source when we’re building a template in Sitecore. A full list of macros can be found in /sitecore/system/Settings/Rules/Definitions/Macros
- compares to, the last parameter is the text representation that we want to show to the content author, this value is clickable and when clicked Sitecore will display the appropriate input control based on the macro that we set on the second parameter
The Type field is the full assembly name of the custom class that we want to use to perform the logic behind this personalization rule
4. Assign our custom element default tag definition to our custom tag
Of course we can assign our custom element tag definition to one of the existing tag under /sitecore/system/Settings/Rules/Definitions/Tags so that it will automatically appear on the content author personalization rule window however if you want to make it obvious which one is your custom ones then I recommend creating your own custom tag and assign it to that
5. Assign the tag to Conditional Rendering
The last step to make the rule visible for the content author to choose from is to assign our custom tag to one of default Rules Context folder
From the picture we’re setting the tag to the Conditional Rendering rules context which will appear when the user want to personalize a certain component, but you can also some other Rules Context folders such as FXM ones.
After we assign the tag, we can verify that the custom personalization rule is available for the content author to choose from
Here’s the class that’s responsible to evaluate the custom rule condition
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
using Sitecore.Analytics; using Sitecore.Diagnostics; using Sitecore.Rules; using Sitecore.Rules.Conditions; namespace Sitecore.Poc.Rules.Conditions { public class TemplateNameCondition<T> : StringOperatorCondition<T> where T : RuleContext { public string Value { get; set; } protected override bool Execute(T ruleContext) { Assert.ArgumentNotNull(ruleContext, "ruleContext"); Assert.IsNotNull(Tracker.Current, "Tracker.Current is not initialized"); Assert.IsNotNull(Tracker.Current.Session, "Tracker.Current.Session is not initialized"); Assert.IsNotNull(Tracker.Current.Session.Interaction, "Tracker.Current.Session.Interaction is not initialized"); var currrentItemTemplateName = ruleContext.Item.TemplateName; return Compare(currrentItemTemplateName, Value); } } } |
The class logic is simple and not doing much for the purposes of the tutorial. In a real world scenario you can make a rule that reads from a custom database, read a configuration file, call an external API (be careful with this as it will increase page load time).
This may sound like a lot of work at first compared to just creating a custom code in the rendering or similar approach. But when we consider that we’re enabling the content author/marketers to do it by themselves and removing/minimizing the dependency towards IT, it would lessen time to market and open up more possibilities for the marketers of what they can do using the platform.
