Product Administration Guide > Configuration Constraint Template Reference >

Set Preference Template

The Set Preference template has the form:

When possible, constrain [an expression] to be true with a [specified priority]

The expression in a preference constraint is enforced as a constraint only if it does not conflict with any other constraint type or with any user selections. The purpose of the Set Preference template is to allow you to create soft constraints that guide the Siebel Configurator engine in producing solutions but which the engine can ignore if needed to avoid conflicts or performance problems.

A key use for preference constraints is to cause a default selection of Item B based on the selection of Item A. This is called a dynamic default. You can set a default dynamically based on a previous user selection. The user can then override the default if desired by choosing a different item than the dynamic default.

For example, you could write the following constraint:

When possible, constrain [Item A requires Item B] to be true with a priority
of [0].

When the user picks Item A, the engine will attempt to create a solution containing Item B. However, the engine is free not to include Item B in order to avoid conflicts and performance problems.

If users do not want Item B, they can remove it without creating a conflict. If you had written the constraint as "Item A requires Item B", Item B would be added when users pick Item A. If users try to remove Item B, they receive a conflict message.

Another use for the Set Preference Template is to set or modify the default value for an attribute. To do this, you would write a preference constraint where the expression, is Attribute A = value. The attribute would then be displayed with this value unless overridden by another constraint.

The priority operand in preference constraints determines the order in which multiple preference constraints for an item are evaluated. Preference constraints with priority 0 that apply to a specific item are evaluated first. Those with priority 1 that apply to that item are evaluated next, and so on.

For example, you have written two preference constraints that apply to a specific relationship. PrefConstraint A has a priority of 0. PrefConstraint B has a priority of 1. The Siebel Configurator engine will attempt to add PrefConstraint A to the solution before attempting to add PrefConstraint B.

Here is how the Siebel Configurator engine creates solutions containing preference constraints:

• The engine generates a solution that enforces all constraints and user choices but does not include preference constraints.
• The engine then adds the preference constraints one at a time for each item. It begins by adding the highest priority preference constraints for an item first. Preference constraints with the same priority are added in arbitrary order.
• If the solution remains valid when a preference constraint is added, then the expression in the preference constraint is enforced as a constraint and becomes part of the solution.
• If adding a preference constraint creates a conflict so that the solution fails, the preference constraint is skipped, and its expression is not enforced. The engine then goes on to the next preference constraint.
• Preference constraints are evaluated after all other constraint types and before the engine searches for and sets default attribute values.

Saved Values for Dynamic Default

Behavior of the Set Preference template depends on whether the Dynamic Default UI property for the product is set to Y during product definition.

If the Dynamic Default property is not specified or is set to N, child components that are deleted are reset to the default value specified in the Set Preference template when a user works on a configuration that was saved earlier.

If Dynamic Default property is set to Y, then child components that are deleted are not reset to the default value specified in the Set Preference template when the user works on a configuration that was saved earlier. The child components are still deleted when the user works on the configuration again.

For example, there is a Set Preference constraint rule that states: Item A requires Item B. When Siebel Configurator is launched, the user selects Item A and the preference constraint triggers the selection of Item B. The user removes Item B by setting its quantity to 0 and then saves the quote. At a later time, the user works on the quote and configures the product again:

• If dynamic default is off, the child component is added to the product, because this is the default in Set Preference, even though the user removed it during the earlier Siebel Configurator session.
• If dynamic default is on, the child component is not added to the product. It is still removed, because the user removed it during the earlier Siebel Configurator session.

Dynamic default applies only to items that are deleted. If the user changes the quantity to a non-zero value or changes any attribute value, the change remains in the next configuration session, and it is not reset to the default value, regardless of whether dynamic default is used.

New Tables for Dynamic Default

If you are upgrading the Siebel application to use dynamic default, this list of the new tables used for dynamic default can be helpful to you for data migration and troubleshooting. The following new tables were added to capture the deleted items between configuration sessions:

• S_ASSET_DEL
• S_ORDER_ITM_DEL
• S_QUOTE_ITM_DEL