Industries-CPQ-Developer Practice Test Questions

Explanation:

In Salesforce Industries (Vlocity) CPQ, assetization is the process that creates Asset records from order line items after order submission and activation. Not all products should become assets, such as one-time fees, virtual services, promotions, or non-fulfillable items.

To make a product not assetizable, you must configure it at the product (EPC) level. Salesforce Industries provides explicit flags for this purpose.

Why options A and B are correct
A. Check the Virtual Item flag in Vlocity EPC
The Virtual Item flag indicates that the product is not a physical or managed asset and should not result in an Asset record.
Common use cases include one-time charges, fees, promotions, and logical or placeholder items.
Marking a product as a Virtual Item automatically prevents asset creation.

B. Check the Not Assetizable flag in Vlocity EPC
This flag explicitly tells the system not to assetize the product.
Even if the product is otherwise eligible, such as recurring or service products, this flag overrides that behavior.
This is the most direct and explicit control for assetization.

Both flags are best-practice, design-time controls and are commonly tested on the Salesforce Certified Industries CPQ Developer (Ind-Dev-201) exam.

Why the other options are incorrect
C. Create a context rule to control assetization in Vlocity EPC
Context rules control qualification, compatibility, and visibility, but they do not control asset creation.
Assetization is not rule-driven in this way.

D. Check the Do Not Assetize flag in Vlocity Cart's line item configuration window
There is no supported cart-level flag to control assetization.
Assetization behavior must be defined before runtime, in EPC.
Cart configuration is too late in the lifecycle to change assetization rules.

Key Exam Takeaway
Assetization is controlled at the product definition level in EPC, not at runtime.
To prevent asset creation, use the Virtual Item flag or the Not Assetizable flag.

Explanation:

These settings are found in the CPQ Configuration Setup (Custom Settings) and are critical for performance in large orders, such as a cart with more than 50 line items.

DeltaPrice (C)
When this is set to true, the pricing engine only calculates the price for the specific line items that have been added or updated.
Without this setting, adding a single item to a large cart would force the engine to reprice every line item, leading to slow response times and potential Apex governor limit issues.

DeltaValidate (D)
Similar to pricing, this setting ensures that Advanced Rules such as Compatibility and Validation only run on the delta, meaning only the changed items.
For example, if a user changes the color on one phone, the engine validates only that specific change instead of re-running validation logic for the entire order.

Analysis of Incorrect Answers
A. CacheAPI.TimeToLiveInDays
This setting controls how long data remains in the Platform Cache, also known as the Vlocity Metadata Cache.
While it improves performance by reducing database queries, it does not control delta-based pricing or validation logic.

B. Cache APIFields
This setting defines which fields are included in cached API responses.
It helps reduce payload size but does not influence how the pricing or validation engines process changes during a transaction.

References
Salesforce Help: CPQ Configuration Settings Reference
Vlocity Developer Guide: Optimizing CPQ Performance with Delta Settings

Explanation:

In Salesforce Industries CPQ (Vlocity), entity filters are reusable components that define subsets of data based on specific criteria. They are commonly used in qualification rules, eligibility rules, and context rules to determine whether a product, promotion, or discount applies in a given scenario.

When an entity filter is created, it is stored as a metadata definition in the system. This means it is not tied to a single rule but instead becomes a reusable resource. Any rule that requires filtering logic can reference the same entity filter without recreating it. For example, an entity filter that selects only products with a status of Active can be reused across multiple rules such as promotion eligibility rules, pricing rules, or validation rules.

This design follows CPQ configuration best practices.

Reusability
Entity filters can be applied across multiple rules, which reduces duplication and configuration effort.

Maintainability
If filter criteria need to change, administrators update the entity filter once, and all rules that reference it automatically inherit the change.

Consistency
Using shared entity filters ensures that rules across the product catalog apply the same filtering logic, preventing inconsistencies and unexpected behavior.

Why "False" is incorrect
If entity filters were limited to a single rule, administrators would be required to duplicate the same filtering logic across multiple rules, increasing maintenance effort and the risk of errors. Salesforce Industries CPQ explicitly supports entity filter reusability, which makes the statement True.

References
Salesforce Help: Industries CPQ Entity Filters, which explains how entity filters are created and reused across rules.
Salesforce Trailhead: Configure Industries CPQ Rules, which provides guidance on using entity filters in qualification and eligibility rules.

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:

This question tests understanding of product lifecycle dates in Salesforce Industries (Vlocity) CPQ and how those dates control which actions are allowed at different points in time.

Product A Dates
Selling Start Date: July 31, 2021
Selling End Date: October 31, 2021
Fulfillment Start Date: July 31, 2021
End of Life Date: October 31, 2022

Evaluation Date
November 22, 2021

Step-by-step reasoning
1. Can the product be added to cart?
No.
Adding a product to the cart requires the current date to fall between the Selling Start Date and the Selling End Date.
Since the Selling End Date is October 31, 2021 and the evaluation date is November 22, 2021, the product is no longer sellable and cannot be added to the cart.

2. Can the product be changed?
No.
Change actions typically apply only to active, sellable products or those still within the selling window.
Once the product is past its Selling End Date, changes such as upgrades or reconfiguration are generally not allowed.

3. Can the product be disconnected?
Yes, this is the correct answer.
Disconnect actions are allowed as long as the product has already been fulfilled and the current date is before the End of Life Date.
Fulfillment started on July 31, 2021 and the End of Life Date is October 31, 2022.
The evaluation date of November 22, 2021 falls between these two dates, so the product can still be disconnected.

4. Can the product be moved?
No.
Move actions usually apply to active, configurable services and are constrained by selling and configuration rules.
After the selling period ends, move actions are generally restricted.

Key Exam Takeaway
After the Selling End Date but before the End of Life Date, a product can still be disconnected but cannot be sold or changed.
This is a common Salesforce Certified Industries CPQ Developer (Ind-Dev-201) exam scenario that tests understanding of selling dates, fulfillment behavior, end-of-life rules, and allowed lifecycle actions.

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, promotions modify the pricing of products within a bundle or a specific set. To achieve a flat charge for a promotion while ignoring the individual costs of the components, you must manage the price aggregation.

Zeroing Child Products
By using the promotion to adjust the price of all child products to zero, you ensure they do not contribute to the rolled-up total of the bundle.

Parent Charge
You then assign the desired flat fee to the Promotion record at the parent level. When the promotion is applied in the Vlocity Cart, the engine calculates the total as:
$0 (Children) + $FlatFee (Parent) = $FlatFee.

Why other options are incorrect
B. Change the price list
Price lists define the base price of products for a market segment, but they do not dynamically override the roll-up logic of a specific promotion applied to a cart.

C. Include only child products with a base price of zero
This is not a scalable solution. Promotions often apply to existing products with standard prices. The promotion should modify their price to zero for that specific transaction, not require them to be zero in the Master Catalog.

D. Limit minimum amount of purchase
This relates to Product Cardinality (quantity), which controls how many items a user must buy, but it has no impact on overriding the price calculation logic.

References
Define Promotion Pricing (Salesforce Help)
Promotions Overview (Salesforce Documentation)

Explanation:

In Salesforce Industries Guided Selling, typically built with OmniScript, the Selectable Items element is used to display a list of products for the user to choose from.

How it works
The element retrieves product data, often via a DataRaptor or Integration Procedure.
It renders the products in a list or grid view with details such as name, price, and image.
Users can select one or more products to add to the cart.

Why the other options are incorrect
A. Done action element – Used to finalize a step or script, not to list products.
C. Step element – Defines a page or section in the OmniScript, but does not directly list products; it contains elements like Selectable Items.
D. Remote action element – Used to call Apex methods or APIs, not to display product lists.

Reference
OmniScript documentation lists Selectable Items as the element for displaying selectable product offers in Guided Selling.

Conclusion
To list products in Guided Selling, use the Selectable Items element (Option B).

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 information is spread across multiple systems, databases, or departments rather than stored in a single, unified source.

In telecommunications companies, this is a major business challenge because:
Customer, product, pricing, and order data often live in silos, such as billing systems, CRM, network systems, or legacy OSS/BSS platforms.
It becomes difficult to get a single view of the customer, ensure data consistency and accuracy, and build real-time quotes and orders, which is critical for Industries CPQ.

Salesforce Industries (Vlocity) CPQ exists largely to solve this problem by orchestrating data across systems through DataRaptors, Integration Procedures, and OmniStudio.

Why the other options are incorrect
A. Beneficial to telecommunications companies
Incorrect. While telcos may operate with non-centralized data due to legacy systems, it adds complexity, cost, and risk, not benefit.

C. A profitable way to aggregate data
Incorrect. Non-centralized data does the opposite of aggregation—it prevents efficient aggregation, leading to slower processes and poor customer experiences.

Reference:
Salesforce Industries CPQ & OmniStudio documentation emphasizes the challenge of disparate data sources and the need for centralized orchestration rather than decentralized storage.
Trailhead: Salesforce Industries Data Integration & CPQ Overview

Exam Tip
If a question mentions telecom, legacy systems, OSS/BSS, or siloed data, the exam almost always frames non-centralized data as a challenge, not an advantage.