When multiple products share the same attributes and require identical constraint logic (for example, making an attribute picklist value default), a common challenge is that standard CML import requires each product to be added to the Constraint Model individually. This becomes unmanageable when dealing with a large product catalog.
In Revenue Cloud Advanced (RCA), CML supports type hierarchies — an inheritance model where a parent type (mapped to a Product Classification) can hold all shared logic, and child products inherit it automatically.
When this is applied:
Important:
Product Classification import in CML is currently only available via the CML Editor. It is not supported in the Visual Builder at this time.
Additionally, The CML structure used to achieve classification-level logic differs depending on the product context:
Prerequisites:
Sample Code - When the product is a standalone product or a bundle parent:
@(virtual = true)type Quote { @(sourceContextNode = "SalesTransaction.SalesTransactionItem") relation beyondProducts : Classification[0..999];
constraint(beyondProducts[Classification].TestAttribute == 'B');}
type Classification { string TestAttribute = ["A", "B"];}
In this example:
Classification is the type mapped to a Product Classification record in Salesforce. All products assigned to that Product Classification already inherit the TestAttribute.
Sample Code - When the product is a child product:
For the CML logic to work on a child product within a bundle, the bundle must be imported into the Constraint Model. The child product then inherits the classification logic from the type hierarchy. Avoid importing all attributes unnecessarily when doing this, as it can increase the CML size.
property allowMissingRelation = true;
type LineItem;
@(virtual=true)type Quote{ @(sourceContextNode = "SalesTransaction.SalesTransactionItem") relation clsCmp: classification;}
type classification : LineItem { @(defaultValue = "i5-CPU 4.4GHz") string Windows_Processor = ["i5-CPU 4.4GHz", "i7-CPU 4.7GHz", "Intel Core i9 5.2 GHz"]; constraint(Windows_Processor == "Intel Core i9 5.2 GHz");
type LaptopBasicBundle : classification { relation bundlep : BundleP { default BundleP(1); }
relation laptopbag : LaptopBag;
relation laptop : Laptop[1..999] { default Laptop(1); }
relation antivirus : Antivirus[1..999] { default Antivirus(1); }}
type BundleP : classification;
type LaptopBag : classification { @(defaultValue = "true") boolean Advance_Ecommerce; string Size;}
type Laptop : classification;
type Antivirus : classification;
In this example:
Common steps in both the scenarios:
Step 1: Open Your Constraint Model in the CML Editor
Note: Product Classification import is not supported in the Visual Builder. You must use the CML Editor for this approach.
Step 2: Define the Virtual Quote Container
At the top of the CML Editor, add the Quote virtual type (type Quote). This is the transaction-level container that holds all product type relations. Every CML model using classifications needs exactly one virtual container.
Scenario A: When the product is a standalone product or a bundle parent
Step 1: Add a type (name: Classification) in CML and map it to the Product Classification Record
This ensures the constraint engine applies the logic to all products under that classification automatically.
Step 2: Define the constraint rule under the Quote type according to the business use case. See the Sample code given in "Description" section for scenario A.
Step 3: Save, Activate, and Test
Note: This rule will only get applied to the standalone and bundle parent products associated with the Product Classification.
Behaviour: As per the example code given in description (Scenario A):
Scenario B: When the product is a child product
Step 1: Set the property "allowMissingRelation" to true
Step 2: Define LineItem and the Classification Type:
Step 3: Import the Bundle and Define Child Types
Step 4: Define the constraint rule under the Quote type according to the business use case. See the Sample code given in "Description" section for scenario B.
Step 5: Save, Activate, and Test
Behaviour: As per the example code given in description (Scenario B):
Variables, Relationships, and Associations in Constraint Models
005385561

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.