Parameters & Rules

Overview

Parameters are the configurable options that end users interact with when using a TwikBot configurator. Rules define the logic that governs how those options behave — what is available, what is dependent on what, and what combinations are valid. Together, parameters and rules form the backbone of any TwikBot product.

Both are defined and managed within the Graph Editor using input and logic nodes.

Parameters

A parameter represents a single configurable attribute of a product — for example, a colour choice, a material selection, a component variant, or a numeric dimension. Every option a customer sees and interacts with in the configurator corresponds to a parameter defined in the product graph.

Parameter Types

Parameter Groups

Parameters can be organised into parameter groups — logical groupings that structure the configuration experience for the end user. Groups are used to present related options together in the configurator UI and to control the navigation flow through the configuration process.

Rules & Constraints

Rules define conditional behaviour between parameters. They ensure that the configurator only allows valid combinations and that the product logic reflects real-world manufacturing constraints.

Types of Rules

Visibility rules — Control whether a parameter is shown or hidden based on the value of another parameter. For example, a stitching colour option might only be visible when a leather interior is selected.

Enable/disable rules — Control whether a parameter is available for selection based on other active values. For example, a specific wheel size might be disabled unless a particular suspension package is selected.

Dependency rules — Automatically set the value of one parameter based on the value of another. For example, selecting a specific trim level might automatically apply a default colour palette.

Constraint rules — Hard restrictions that prevent invalid combinations from being selected regardless of user input.

Building Rules in the Graph Editor

Rules are implemented using logic nodes in the Graph Editor. Each rule is constructed by connecting input nodes (the conditions) to logic nodes (the evaluation) and output nodes (the effect on other parameters).

When building rules, consider the following:

• Build and test rules incrementally as you go — complex rule sets are significantly harder to debug when tested in bulk at the end of a build

• Document the logic behind non-obvious rules so they can be maintained or modified later by you or the client's team

• Validate rules against the full product specification provided during the discovery phase, not just the obvious cases

Best Practices

• Keep parameter groups shallow — Too many levels of nesting makes the configurator harder to navigate for end users

• Name parameters clearly — Use names that are meaningful to the end user, not internal technical identifiers

• Test edge cases — Always test the boundaries of numeric parameters and less common option combinations, not just the default path through the configurator

• Plan for localisation early — If the product will be deployed in multiple languages, structure parameter names and labels with translation in mind from the start

Developer Resources