Skip to content
iDialogue Docs

Configuration Data Model

iDialogue Product Configurators are defined using 3 primary objects:

  • Configuration
  • Card
  • Option

Configuration objects may be related to many other objects throughout the configuration lifecycle.

The configuration data model provides an abstraction layer that decouples the customer experience from the actual quotes and opportunities in a CPQ or Sales system.

This allows for more internal flexibility when collaborating with customers and ensures any self-service “what-if” scenarios do not break the master quote.

This will appear if the image fails to load

Configuration

Two types of configurations exist. Template and Instance.

Template Configuration

A template represents a default configuration made available to anonymous website visitors, prospective customers, or qualified opportunities. They are the initial starting point for any product configuration.

Templates may also be used by Marketing to model potential offerings and proposals to specific segments of customers.

A template is not associated with any particular customer quote.

Instance Configuration

Once a Lead, Contact, or internal Sales user interacts with a template, then a cloned instance is created.

Instance configurations are associated with Lead, Opportunity, Quote, SBQQQuotec, or any object within the quote to cash lifecycle.

An opportunity or quote may iterate over the same instance configuration. Or many configuration instances may be created if a customer wants to review options side-by-side.

Card

A configuration card is a visual metaphor for what the customer actually “sees” as a general configuration category. A card typically 1:1 maps to a navigation item on a configurator.

For example, the GenWatt demo is comprised of 3 cards:

  1. Color
  2. Fuel
  3. Power

A Card object is a parent to many Option records.

Option

When customers personalize or configure a product, they are interacting with Option records. An option’s selected boolean property is used to trigger quote configuration rules.

Example: if a product is available in 3 colors; red, green and blue; then the Card for “Color Options” will contain 3 child option records. One for each color. Only one of the color option records will have the state of selected = true.

Modeling Dependencies

Dependencies are common in product configurators. For example, selecting one product option may open up a range of new options. Or conversely, selecting an option may exclude other product options.

These dependencies and rules may be modeled either as hierarchical decision trees or option groups.

Hierarchies / Decision Trees

Options and Cards are self-referential. Much like building an Account hierarchy, cards and options may be combined into hierarchies that mirror decision trees, such that choosing one option makes available a collection of child cards and options.

Option groups

If a particular card drives dependency logic, then the dependency controlling card may define all possible child options in “groups”. The JS client is configured to filter cards based on a selected group. This is a “flatter” and simpler data model, but requires a little more business logic in the JS client.

JS Clients

Product configurator JS (Javascript) clients are developed in conjunction with data models. See the SDK section for details on how to build a custom product configurator.

Regardless of which model is defined, the configuration.publish() event results in a JSON structure that represents the configuration model.