Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), Tightest Match logic is used to determine the best match when multiple rule conditions apply—commonly in Pricing, Eligibility, and Configuration Rules.

Tightest Match evaluates conditions using weights, and it behaves differently depending on the logical operator:

AND conditions
- All conditions must be met
- The weights of all matched AND conditions are summed
- A higher total weight means a tighter (better) match

OR conditions
- Only one condition needs to be met
- The system selects the highest weighted condition among the matched OR conditions

Because both statements correctly describe Tightest Match behavior, the correct answer is C.

Why the other options are incomplete
A. AND rule condition weights are summed together ❌
True, but only describes part of Tightest Match logic.

B. OR rule conditions select the highest weighted value ❌
Also true, but incomplete on its own.

Key Exam Tip
If a question mentions Tightest Match, always think:
AND → sum of weights
OR → highest weight wins

Salesforce loves testing this distinction because it’s unique to Industries CPQ, not standard Salesforce CPQ.

Reference
Salesforce Industries CPQ Rule Engine Documentation
Trailhead: Industries CPQ Rules and Pricing

Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), a configured line item does not always need to be removed and re-added in order to change its configuration.

Vlocity Cart supports in-place reconfiguration of products. Users can:
- Reopen the configuration UI for an existing line item
- Modify attributes, options, and child products
- Re-run configuration and pricing logic without deleting the product

This behavior is fundamental to Industries CPQ, especially for complex product hierarchies and guided selling flows.

Why the other option is incorrect
A. True ❌
This is a common misconception. Removing and re-adding products is not required unless:
- The product model explicitly restricts reconfiguration
- Certain lifecycle or eligibility rules block changes
- The configuration is locked by custom logic or orchestration

None of these are default or mandatory behaviors in Vlocity Cart.

Key Exam Tip
Salesforce Industries CPQ emphasizes:
- Dynamic reconfiguration
- Reusable product models
- Cart-level flexibility

If the exam suggests that a product must be removed to change configuration, it’s usually false unless explicitly stated.

Reference
Salesforce Industries CPQ (Vlocity) Product Configuration Guide
Trailhead: Industries CPQ Basics
Vlocity Cart & Configuration Documentation

Explanation:

In Salesforce Industries CPQ (Vlocity), when working with asset-based ordering, you can generate a quote from an existing asset by using the Change to Quote action. This action allows you to take the customer’s current assets (e.g., subscribed products or services) and create a new quote that reflects modifications, upgrades, or cancellations.

Let’s break down the distractors:

B. From the Quotes tab
→ You can create new quotes here, but not directly from existing assets.
C. From the Opportunities tab
→ Quotes can be linked to opportunities, but this is not how you generate a quote from assets.
D. From the Orders tab
→ Orders reflect fulfilled quotes; they don’t generate quotes from assets.

The Change to Quote action is specifically designed for asset-based scenarios, making A the correct answer.

Reference:
Salesforce Industries CPQ Documentation – Asset-Based Ordering and Change to Quote

Explanation:

In Salesforce Industries CPQ (formerly Vlocity CPQ), Context Rules can indeed be applied to order line items.
Context Rules (Qualification, Eligibility, Pricing, etc.) are not limited to the catalog, product selection, or quote stage — they can also evaluate and affect order line items after the order has been created/submitted.

Key scenarios where Context Rules apply to order line items:
- Pricing Context Rules — Can adjust or override pricing on order line items based on runtime context (e.g., account attributes, order date, location) during order processing or fulfillment.
- Eligibility/Qualification Context Rules — Can be configured to run in the order context (root scope = Order or OrderItem) to validate or disqualify line items post-submission (e.g., "This add-on is only allowed on orders with Premium SLA").
- Order Management integration — When decomposition occurs or during orchestration, context rules can evaluate order line items to determine fulfillment paths, penalties, or adjustments.
- Assignment — You can assign a Context Rule Set to the Order object or OrderItem (via object type or directly), so the rules evaluate against order line item data.

This is especially important in industries like Communications, where order line items may need dynamic pricing, validation, or eligibility checks after cart submission (e.g., regulatory rules, location-based restrictions, or time-sensitive adjustments).

Why it's not False:
The statement is accurate — Context Rules are flexible and support multiple root scopes, including Order and OrderItem, allowing them to be applied directly to order line items.

Reference
Salesforce Help: "Context Rules Root Scopes" — Lists Order and OrderItem as valid root scopes for context rules, enabling evaluation on order line items.
Trailhead: "Context Rules for Orders" and "Advanced Context Rules" — Demonstrates assigning rules to order-related objects and evaluating conditions on order line items (e.g., pricing or eligibility post-cart).

Explanation:

In Salesforce Industries CPQ Guided Selling, the initial price list ID for the Cart is set during the cart creation process, which is typically triggered by the createCart remote method. To pass the correct price list, developers must edit the JSON payload of the remote action that invokes createCart.

✅ Why C is correct:
The createCart method accepts parameters like:

priceListId
accountId
effectiveDate

These values are passed in the JSON configuration of the remote action.
This setup ensures the Cart is initialized with the correct pricing context before any products are added.

❌ Why the other options are incorrect:

A. Set the price list when you create the order
Incorrect: The price list must be set before the order is created — during Cart creation. The order is a downstream artifact.

B. Link the price list Id to the checkout remote method and the order
Incorrect: The checkout method finalizes the Cart into an order. It does not set the initial price list.

D. Add the account number of the customer's account and the current date
Partially correct but incomplete: While these values are often included in the createCart payload, they do not set the price list ID unless explicitly passed.