Explanation:

In Salesforce Industries CPQ (Vlocity Cart), the Display Name field of an Attribute Category is what appears at run-time during order capture in the Cart. This field serves as the section heading in the product configuration window, helping users visually group related attributes.

For example:
If you create an attribute category called "Mobile Devices" and set its Display Name to "Smartphone Specs", that label will show up in the Cart UI as the header for attributes like Brand, Capacity, or OS.

This improves:
User experience by organizing attributes clearly
Sales efficiency by guiding reps through configuration
Data accuracy by ensuring attributes are grouped logically

❌ Why the other options are incorrect:

A. Name: Used internally for identification, not shown at run-time.
C. Category: Refers to the type of attribute grouping, not a display label.
D. No Attribute Category fields display at run-time: Incorrect—Display Name absolutely does.

Explanation:

In Salesforce Industries CPQ (formerly Vlocity):
Promotions can apply discounts to:

The main (parent) product
Specific child products in a bundle

Each discount in a promotion can have its own Time Plan or affectivity period, which:

✅ Defines:
Start date
End date
Duration (e.g. “3 months free”)

This allows a discount on a child product to expire before the promotion itself ends or to only apply during a certain period. For example:

Promotion duration → 12 months
Discount on child product → valid only for the first 3 months
Hence, to limit the duration of a discount on a child product’s price, you should:

✅ Use the time plan on the child product’s discount.

Why not the other options?

A. The time plan on the entire promotion
Controls the global duration of the entire promotion, not individual child discounts.

B. The time policy of the promotion
Similar to A—applies to the overall promotion duration, not child-level discounts.

D. The override of the child product's cardinality
Cardinality controls quantity rules (min/max/default), not discount durations.

✅ Example
Promotion: “Family Bundle Discount” → valid Jan 1 – Dec 31
Discount on Child Product (e.g. streaming service):
Time Plan → valid Jan 1 – Mar 31 only
Discount = 100% off

→ The child product’s discount stops after March 31, but the overall promotion continues for the rest of the year.

Explanation:

To prevent a product from being tracked as an asset in Salesforce Industries CPQ, developers can use the following two best-practice methods:

C. Check the Is Not Assetizable property
This flag is set on the product record in Vlocity EPC. When enabled, it ensures the product is excluded from asset creation during the order lifecycle. This is ideal for promotional items or virtual services that don’t require tracking.

D. Check the Virtual Item property
Marking a product as a Virtual Item also prevents it from being assetized. Virtual items typically represent non-physical or non-trackable components like setup fees, digital services, or bundled discounts.

These two flags work independently or together to ensure products are orderable but not tracked in the customer’s asset list.

❌ Why the other options are less effective:

A. Create a context rule to control assetization
Context rules manage eligibility and visibility, not assetization behavior. They don’t prevent asset creation.

B. Check the Do Not Assetize property in the Cart's line item configuration window
This is a runtime setting, not a persistent product-level configuration. It’s not reliable for consistent assetization control across orders.

Explanation:

In Salesforce Industries CPQ (formerly Vlocity), when users configure products in the cart, there may be:

Discounts
Promotions
Markups
Manual overrides
Tax or fees

To help users understand how the final price was calculated, the cart includes the Price Details icon next to each line item.

✅ Price Details icon allows users to:

See the Base Price.
View each pricing element applied:

Discounts
Promotions
Surcharges
View any manual price overrides.
Understand how the final price was calculated.

Hence, the correct answer to:
“How can a user understand changes to pricing applied in the cart?”
is clearly:

✅ C. By clicking the Price Details icon on the line item

Why not the other options?

A. The display text in the Products list in the cart
❌ Incorrect. The product list might show the total price but does not explain how pricing was calculated.

B. Popup message window after the order is submitted
❌ Incorrect. Pricing breakdown is available during cart configuration, not only after submission.

D. Pricing adjustments do not display in the cart
❌ Incorrect. Pricing adjustments absolutely do display in the cart through the Price Details icon.

Example
User sees:
iPhone X → $850.00

Clicks the Price Details icon:

Base Price: $999.99
Promotion: -$50.00
Manual Discount: -$99.99
Total Price: $850.00

Explanation:

Making a Product Non-Assetizable in Vlocity EPC:
To prevent a product from being converted to an asset after order fulfillment:

Option A: Enable the Virtual Item flag (for services/digital goods with no physical asset).
Option B: Enable the Not Assetizable flag (explicitly blocks asset creation).

Why Options A & B?

Virtual Item: Implies the product is a service (e.g., "Installation") and skips asset tracking.
Not Assetizable: Hard override to exclude from assetization (e.g., one-time fees).

Reference: Vlocity Product Configuration

Why Not C & D?
C: Context rules manage pricing/logic, not assetization.
D: No "Do Not Assetize" flag exists in cart configuration.

Explanation:

In Salesforce Industries CPQ (formerly Vlocity), every time the user changes something in the cart:
The system may:

Re-run configuration rules
Re-run pricing calculations
Validate line items
Without optimization, this sends the entire cart payload on every update → very large data sets → slower performance.

To avoid this, Vlocity introduced Delta Mode, which allows the system to send only the changed (delta) line items to the configuration and pricing engines instead of the entire cart.

✅ DeltaPrice
When set to true:
Only changed line items are passed to the pricing engine for recalculation.
Significantly improves performance in large carts.

✅ DeltaValidate
When set to true:
Only changed line items are passed to the configuration rules engine for validation.
Prevents unnecessary re-processing of the entire cart.

These two settings help reduce:
API payload sizes
Processing times
Server load

Hence, for the question:

Which two custom settings need to be set to true in order to avoid passing large sets of items to the configuration rules and the pricing engine?

✅ The correct answers are C. DeltaPrice and D. DeltaValidate.

Why not the others?

A. CacheAPI.TimeToLiveInDays
Controls how long API cache entries persist.
Unrelated to delta processing.

B. Cache APIFields
Used to cache specific API field values to improve performance.
Not related to delta processing for pricing or rules.

Explanation:

In Salesforce Industries CPQ, once you create an entity filter, it becomes a reusable component that can be applied to any rule that requires it. This includes:

Pricing Rules
Compatibility Rules
Eligibility and Availability Rules
Advanced Rules
Entity filters are designed to:
Target specific line items or objects based on conditions
Be modular and shareable across multiple rule actions
Improve rule maintainability by centralizing logic

For example, if you create a filter to identify products with a status of "Active" and a minimum quantity of 1, you can reuse that filter in multiple rules—such as one that applies discounts and another that validates configuration.

Explanation:

In Salesforce Industries CPQ (formerly Vlocity), the Line Item Configuration window in the Cart allows the user to modify details specific to each product in the cart. Among the configurable fields are:

✅ A. Service account
Refers to the account that will receive the service associated with this product.
Used in B2B and B2C flows to link the product to the correct customer account or sub-account.

✅ B. Billing account
Refers to the account responsible for billing the charges associated with this product.
Especially critical in multi-account or enterprise scenarios where the service and billing accounts are different.

These two fields are commonly editable in the line item configuration because:
They control who owns the product and who pays for it.
Users may need to select different accounts for different products in the same order.

Why not the others?

C. Prices
❌ Not directly editable in the line item configuration window.
Prices are controlled via:
Pricing logic
Promotions
Manual overrides (done outside the configuration window, e.g. via the Price Details window or specific override fields).

D. Applied promotion
❌ Promotions are typically added or removed at the cart level, not directly adjusted in the line item configuration window.
The window might show that a promotion has been applied, but it’s not where you modify the promotion itself.

✅ Example
In the Line Item Configuration window for “iPhone X,” you might see:
Service Account: [Dropdown or lookup]
Billing Account: [Dropdown or lookup]
...
Other attribute fields

But not:
Editable fields for prices
Editable applied promotions

Explanation:

Product Lifecycle Dates:

Selling Period: July 31 – October 31, 2021 (product can be sold).
Fulfillment Period: July 31, 2021 – October 31, 2022 (service is active).

November 22, 2021 Status:
Selling Ended: Cannot be added to cart (A) or moved (D).
Fulfillment Active: Can only be disconnected (terminated).

Why Option C?
Disconnect: Valid for active fulfillments (e.g., canceling a subscription).

Reference: Salesforce CPQ Product Lifecycle

Why Not Other Options?

A (Add to Cart): Blocked post Selling End Date.
B (Change): Requires active selling period.
D (Move): Requires active selling/fulfillment.

Explanation:

In Salesforce Industries CPQ (formerly Vlocity):
Qualification Entity Filters:

Determine which records in a specific entity (e.g. cart items, assets, orders) should be evaluated by a rule.
Essentially answer: “Which items should the rule check?”

Evaluation Entity Filters:
Act as internal filters that further refine the set of records selected by the Qualification Entity Filters.

Essentially answer: “Of the items the qualification filter found, which ones actually meet the detailed conditions for this rule?”

So the typical flow is:
Qualification Entity Filter → identifies potential candidates
Evaluation Entity Filter → checks detailed conditions on those candidates
Hence, evaluation entity filters are indeed “internal filters” for qualification entity filters.

Example:
Qualification Entity Filter:
Selects all products where Type = Mobile.
Evaluation Entity Filter:
Further filters those products to:
Price > $100
Status = Active
Only items matching both filters trigger the rule.

Why not False?
This is exactly how the rule framework works in CPQ:
Qualification = outer filter.
Evaluation = internal filter.
Hence, the statement is true.

Explanation:

In Salesforce Industries CPQ, when you want to price a promotion with a flat charge, the best practice is to:

Zero out the base prices of all child products
Assign the total promotional price to the parent product

This ensures that:
The rolled-up pricing from child products doesn’t inflate the bundle price
The promotion appears as a single flat charge in the cart
The pricing logic remains clean and easy to maintain

This method is especially useful for bundled promotions where the individual product prices are irrelevant to the customer-facing quote.

❌ Why the other options fall short:

B. Change the price list: Doesn’t control how child product prices roll up or how promotions behave.
C. Include only child products with base price of zero: Too restrictive and not scalable—better to override prices dynamically.
D. Limit minimum purchase amount: This affects quantity constraints, not pricing behavior.

Explanation:

Guided Selling in Salesforce CPQ/Vlocity:
The Selectable Items element is used to display and allow selection of products in a Guided Selling flow.
It dynamically lists products based on rules (e.g., eligibility, compatibility).

Why Option B?

Core Functionality:
Renders products as clickable options (e.g., tiles, dropdowns).
Connects to backend APIs like getOffersByCatalogCode.

Reference: Vlocity Guided Selling Elements

Why Not Other Options?
A (Done action): Ends the flow, doesn’t list products.
C (Step element): Groups sections but doesn’t display items.
D (Remote action): Fetches data but doesn’t render it.