Rules engine
The Customizer platform includes a rules engine that allows to model complex relationships between product components or to implement specialized business logic actions.
Currently, there are two ways to configure available components on products:
Component rules
Rules engine
Both methods work together to create configurable products. Component rules allow to select which options are available for specific placements. However, they do not allow to model relationships between different placements. On the other hand, rules engine does not specifically list out available components, but instead allows to turn on and off options based on other placements.
When to use… | |
|---|---|
Component rules | Select which options are available on a placement. For example, which Fonts can be used on a Personalization placement |
Rules engine | Turn on an option only in specific situations For example, allow a Text Color only on specific base product Colorway (e.g. allow Glitter only specific base products) |
Rules engine | Turn off an option if some conditions are met For example, disable a Text Color option on specific base products (e.g. prevent personalization printing in Black on Black leather) |
Tags
Instead of relying on component or placement codes, the rules engine works on tags. This allows for greater flexibility and enables rules to work on groups of options instead configuring component-by-component basis.
For example, a number of Text Colors can be tagged as dark-text, and a number of product Colorways can be tagged as dark-product. A rule such as block dark-text if dark-product is selected would apply to any dark text color without having to create a set of explicit rules.
Tag Activation
Rule descriptions below mention tag activation. A tag will be activated if it is present in the current configuration state of a product:
A tag appears on the product itself
A tag appears on any of the currently selected components
Rule types
Customizer supports a number of rule types, and rules may include complex boolean conditions (i.e. if tag1 and tag2 ...). Some more complex configurations currently can be set up only through the API or ETL layer, and simpler rules can be configured through Customizer Admin.
Rules precedence
Rules are evaluated as a complete set, regardless of the order in which they are configured. Always Enabled rules have a highest importance, followed by Block rules, meaning if a component was enabled by Only When type rule, it can still be disabled by a Block rule.
Admin configurable rules
Rule Type | Rule Description | Configuration Parameters |
|---|---|---|
Always Enabled… | A component with specific tag will always be enabled, even if a tag is disabled by a | A list of tags to turn on |
Blocked If Any… | A component with configured tag will be disabled if any of target tags are activated. For example,
| A list of tags to turn off if conditions are met A list of tags to serve as triggers for conditions |
Blocked If All… | A component with configured tag will be disabled if all of target tags are activated For example,
| A list of tags to turn off if conditions are met A list of tags to serve as triggers for conditions |
Only When Any… | A component with configured tag will be disabled by default. It will be enabled only if any of the target tags are activated For example,
| A list of tags to turn on if conditions are met A list of tags to serve as triggers for conditions |
Only When All… | A component with configured tag will be disabled by default. It will be enabled only if all of the target tags are activated For example,
| A list of tags to turn on if conditions are met A list of tags to serve as triggers for conditions |
Coded rules
Coded rules can be configured through the ETL process at the moment. See Coded rules page for more details.