Explanation:

In Salesforce Industries CPQ (Vlocity), Context Rules are driven by the concept of a root entity, which defines the context or scope in which rules should apply (such as during quoting, asset-based ordering, or contracting).

These root entity context scopes are the top-level Salesforce objects that serve as the entry point for rule evaluation. These are:

Order
Opportunity
Quote
Asset
Account
Contract

These objects serve as valid scopes when configuring context rules, including Qualification and Evaluation Context Rules. Rules inherit field values from the root context and evaluate conditions accordingly.

Why the Others Are Incorrect:
G. Product ❌ Not a context scope—products are evaluated within the context, but not as a root entity themselves
H. Order Line Item ❌ This is a child of Order—not a root-level entity for context evaluation

Explanation:

When dealing with bundles in Salesforce Industries CPQ, you have two primary pricing strategies:

✅ 1. Parent-Priced Bundles
The parent product carries the entire price of the bundle.
All child products are priced at $0 (zero price).
The price of the bundle does not vary based on the selection of child products unless adjustments are explicitly configured.
This simplifies pricing for fixed bundles.

Example:
Bundle Product → “Mobile Data Plan”
Parent price = $50/month
Child products = $0 (included)

✅ 2. Summed Pricing (Component Pricing)
Each child product carries its own price.
The bundle price = sum of all child products’ prices.
Flexible for “build-your-own” or configurable bundles.

Example:
Parent → “Internet Plan”
Modem Rental → $10/month
Speed Upgrade → $5/month
Total bundle price = $15/month

✅ Option A is Correct
✅ Price the child products as zero and assign a flat rate to the parent product.
This is a textbook example of parent-priced bundles in Industries CPQ.

Why the Other Options Are Incorrect
✅ B. Use multiple price lists to assign more than one price to a product → Incorrect
That’s a technique for multi-region or multi-currency pricing, not specifically for bundle pricing.

✅ C. Change the display text of a price list entry to show the starting price → Incorrect
Changing display text affects how prices are shown to users, but it’s not a pricing method for handling bundles. It’s purely cosmetic.

Explanation:

In Salesforce Industries (Vlocity), products can be configured with the Assetizable flag:
- When enabled (true), the product creates assets when sold (e.g., devices, service plans)
- When disabled (false), no assets are created (e.g., one-time fees)
- Controlled by the vlocity_cmt__IsAssetizable__c field on Product2

Why Other Options Are Incorrect:
B. Assets don't need marking - this flag applies to products, not existing assets
C. Non-assetizable doesn't mean promotional - promotions use price rules
D. Promotions are managed separately through pricing configurations

Explanation:

In Salesforce Industries CPQ (Vlocity), when you need to evaluate Order Line Items—especially for compatibility across selected products or services—Advanced Rules with type Configuration Validation (Compatibility) are the right tool.

These rules allow evaluation of relationships between products and services, such as:

“Product A cannot be sold with Product B”
“If Product C is selected, then Product D must be included”
“Only one item from Group X is allowed per order”

They operate after product selection, validating selections inside the Cart or Order Line Items against compatibility logic, making them perfect for use cases that depend on how items coexist in the cart.

Why Other Options Don’t Apply:
B. Context Rule – Qualification ❌ Used to determine product eligibility in a catalog or basket—not for validating order line items
C. Advanced Rule – Eligibility ❌ Determines whether a product is eligible for display/selection—not compatibility after selection
D. Advanced Rule – Availability ❌ Controls time or geography-based availability, not post-selection validation of line items

Explanation:

When a user opens the Vlocity Cart, the platform needs to determine which products to display in the catalog. The rules engine processes various rules in a specific order to progressively filter and validate products.

Here’s the correct sequence:

✅ 1. Context Rule – Qualification
✅ This is the first rule type processed.

Determines whether a product should appear in the catalog for the customer.
Filters products based on:
Account attributes (e.g. segment, region)
Opportunity data
Customer eligibility for specific offers

Example:
“Only show B2B internet plans for accounts with Segment = Enterprise.”
If a product fails a qualification rule, it’s never shown in the catalog at all.

✅ 2. Advanced Rule – Eligibility
Runs after qualification.
Further filters products based on:
Product-specific eligibility conditions
Dynamic product attributes

Example:
“This mobile plan is only eligible for customers over 18 years old.”

✅ 3. Advanced Rule – Availability
Determines whether a product is available based on:

Inventory
Location-specific constraints
Serviceability

Example:
“Fiber internet is only available in specific zip codes.”

✅ 4. Advanced Rule – Configuration Validation (Compatibility)
Runs last.
Validates compatibility among selected products in the cart.
Ensures no conflicting combinations exist once products are added to the cart.

Example:
“If Product A is selected, Product B cannot also be selected.”
Compatibility checks don’t run until products have been chosen and configurations exist.

Why the Other Options Are Incorrect
✅ B. Advanced Rule – Availability → Incorrect
Processed later in the chain—not first.

✅ C. Advanced Rule – Eligibility → Incorrect
Runs after qualification rules.

✅ D. Advanced Rule – Configuration Validation (Compatibility) → Incorrect
Runs last, during or after product selection in the cart.

Explanation:

To build a Guided Selling cart in Vlocity, you need:

createCart method → Initializes the cart instance.
Price List/Book → Required for product pricing and availability.
HTML Template → Defines the cart's UI layout (horizontal/vertical).
Valid Account → Essential for customer-specific pricing and eligibility.

Why Not the Others?
E. User profiles → Not mandatory (cart rules typically use account/price lists, not profiles).
F. Multiple price lists → Optional for advanced filtering, not core to basic setup.
G. getCartsItems linking → Handles cart rendering, not initial construction.

Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), product life cycle management is critical. Products have various date fields that determine:

When they can be offered for sale
When they’re no longer sellable
When they’re fulfilled or end-of-life

One visual clue in the Cart UI is the fifed (flagged) dock icon (sometimes displayed as a small alert or calendar icon) next to a line item. This icon indicates:

✅ The product’s Selling End Date is approaching or has passed.

✅ Selling End Date
Controls the last date a product can be sold.
Once the Selling End Date passes:
The product is no longer eligible for new orders.
Users may receive warnings or errors in the Cart.
The UI flags these products so sales reps know they’re about to go off-market.

Example:
Selling End Date = July 15
Today’s date = July 10
→ Cart shows an icon next to the product line to warn the rep.

Why Other Options Are Incorrect
✅ B. End of Life Date → Incorrect
End of Life Date indicates when a product is no longer supported or maintained by the business.
It doesn’t directly determine selling eligibility or appear as a flagged icon in the cart.

✅ C. Fulfilment Start Date → Incorrect
Indicates when fulfillment can start (e.g. service activation date).
Does not affect whether a product is sellable.

✅ D. Selling Start Date → Incorrect
Defines when a product becomes available for sale.
If it’s before the Selling Start Date, the product won’t appear in the catalog at all.
There’s no icon to indicate a product is “not yet sellable” in the cart.

Explanation:

Guided Selling requires a persistent cart to:

Maintain cart visibility across multiple steps of the selling process.
Allow users to review/modify selections while navigating through different stages (e.g., product selection → configuration → checkout).
Prevent data loss when moving between steps.

Why Not the Other Options?
A. Incorrect → The persistent cart doesn’t "prevent" the regular cart; it enhances it for guided workflows.
C. Incorrect → OmniScript launch is handled by actions, not cart persistence.
D. Incorrect → Step titles/instructions are managed by OmniScript layouts, not the cart.

Explanation:

In Salesforce Industries CPQ (Vlocity), when you're configuring an entity filter to evaluate product attribute values, you must specify the Attribute Lookup Field Name. This tells the rules engine where to find the attribute values during rule evaluation—particularly when you're working with Context Rules, Advanced Rules, or Pricing Adjustments based on attributes.

Here’s why it matters:

The Attribute Lookup Field Name is used to navigate from the root or child entity to the record that contains the actual Attribute-Value pairs (often via the ProductAttribute or AssetAttribute relationship).
Without this field, the rule won’t know how to resolve the path to the attribute value, and evaluation would fail or return null.
This is essential in rules that trigger based on configurations like: “If Color = Blue AND Storage > 128GB…”

Why the Others Are Incorrect:
A. Entity Filter Type ❌ Required for overall filter configuration (e.g., RuleCondition or Qualification), but not specific to attribute lookup
B. Evaluation Criteria ❌ Refers to how filters are combined (e.g., ALL, ANY)—not how to reach attribute values
C. Formula for Conditions ❌ Used for calculated logic, but doesn’t help locate attribute fields in related records

Explanation:

Promotions are typically used for:
- B: Customer-specific pricing (e.g., VIP discounts)
- C: Targeted availability (e.g., B2C-only offers)
- E: Time-bound deals (e.g., holiday sales)

Why Not Others?
- A: Cancellation penalties are contract terms, not promotions
- D: Urgent sales are inventory/operations issues

Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), Product Relationships are crucial for managing how products:

Must be sold together
Cannot be sold together
Are recommended to customers

These relationships are set up in the CPQ data model and enforced by Configuration/Validation Rules.

Let’s analyze each option.

✅ A. Requires → Correct
Indicates that if Product A is selected, Product B must also be selected.

Example:
“If you sell a security system, you must also sell an installation service.”
This relationship is mandatory.

✅ B. Excludes → Correct
Indicates that if Product A is selected, Product B cannot be selected.
Used to prevent incompatible or conflicting product combinations.

Example:
“Unlimited Data Plan excludes the Limited Data Plan.”

✅ C. Recommends → Correct
A soft relationship that suggests complementary products.
The customer can accept or ignore the recommendation.
Often displayed as:

“Customers who bought this also bought…”

Example:
“Buying a mobile phone recommends purchasing a phone case.”

Why the Other Options Are Incorrect
✅ D. Optional → Incorrect
“Optional” describes whether a child product is required in a bundle, but it’s not a formal relationship type in the rules engine.

✅ E. Limited Quantity → Incorrect
This is a business rule constraint, not a relationship type.
Managed via cardinality or rule actions, not a relationship like Requires, Excludes, or Recommends.

✅ F. Suggests → Incorrect
No official relationship type called “Suggests.” That’s simply another word for “Recommends,” but not a technical type in Vlocity CPQ.

✅ G. Not Compatible → Incorrect
“Not Compatible” is the business result of an Excludes relationship but is not itself a relationship type.

Explanation:

The postCartItems remote method in Vlocity (Salesforce Industries) CPQ is used to add items to the cart.

Primary Function: It takes a list of products or configurations and inserts them into the shopping cart (either a new or existing cart).

Common Use Case: When a user selects products from a catalog or an OmniScript, this method is called to add them to the cart before checkout.


Not Used For:
Submitting an order (B) → Typically handled by submitOrder or placeOrder methods.
Filtering products (A) → Done via queries or getCarts/getProducts methods.
Moving orders to next stage (E) → Managed by order workflows or OmniScript navigation.
Selectables list (C) → Usually populated via getProduct or getSelectableItems methods.