Industries-CPQ-Developer Practice Test Questions

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.

Explanation:

In Salesforce Industries CPQ, attribute-based pricing allows you to dynamically calculate product prices based on selected attribute values (like size, color, connectivity, etc.). The two key features that enable this are:

A. Pricing Plans
These define a sequence of pricing steps. Each step can invoke a lookup table, expression set, or calculation procedure to determine the price based on attribute combinations. Pricing plans orchestrate the logic behind attribute-based pricing.

D. Calculation Procedures & Matrices
These are used to store and evaluate pricing logic. You define attribute combinations and their corresponding prices in calculation matrices, and use calculation procedures to retrieve the correct price during cart operations.

Together, these components form the Business Rules Engine that powers attribute-based pricing.

❌ Why the other options are incorrect:

B. Product Configuration Procedure
This governs how products are configured, not how they’re priced. It’s used for setting up Guided Selling flows and attribute visibility—not pricing logic.

C. Context Rules
These filter products and price list entries based on customer or cart context. While they influence eligibility, they don’t calculate prices based on attributes.

Explanation:

Non-centralized data means data is:

Scattered across many systems
Maintained in silos
Inconsistent across departments
Difficult to reconcile

In the telecommunications industry, non-centralized data causes significant business challenges because:

Customer information may exist in multiple systems (CRM, billing, network, etc.).
It’s difficult to present a single view of the customer.
Product catalogs may differ between sales channels.
Longer implementation times for new offers.
Harder to automate and streamline processes like quoting, ordering, and service delivery.

Hence, the correct answer is:

✅ B. A business challenge for telecommunication companies

Why not the others?

A. Beneficial to telecommunications companies
❌ Incorrect. Non-centralized data is a disadvantage, not a benefit.

C. A profitable way to aggregate data
❌ Incorrect. Non-centralized data is the opposite of profitable aggregation—it leads to inefficiencies and higher costs.