Industries-CPQ-Developer Practice Test Questions

Explanation:

Asset-Based Ordering (ABO) is a feature in Salesforce Communications Cloud that enables customers to modify, upgrade, or cancel existing services and products. This process requires real-time interaction with customer assets and downstream systems to ensure accurate fulfillment and minimal disruption.

The key OmniStudio features involved are:

✔️ OmniScripts:

Serve as the front-end user interface
Collect and guide user inputs for change orders (add, modify, disconnect, suspend, etc.)

✔️ Integration Procedures:

Act as the orchestration layer
Fetch and update customer assets from Salesforce and external systems
Interact with Industry Process APIs (like GetAsset, SubmitOrder, etc.)

Together, these two ensure both a dynamic UI and seamless backend interaction—essential for effective ABO flows.

Why the Others Are Incorrect:
B. FlexCards and OmniScript ❌ FlexCards are used for displaying data, not for processing orders
C. Calculation Procedures and Matrices ❌ These are used in pricing and eligibility, not asset-based logic
D. OmniScript and Calculation Matrices ❌ Matrices aren't used for manipulating assets; IPs are the correct orchestration tool

Explanation:

Correct Option: 🟢 B. Discounting the price by 20%
Discounting the price by 20% requires a calculation that uses the product's original price. For example, if a product costs $100, a 20% discount is calculated as $100 × 0.20 = $20, resulting in a new price of $100 - $20 = $80. This process directly relies on the original price to determine the discounted amount, a common feature in Salesforce Industries CPQ pricing rules.

Incorrect Option: 🔵 A. Completely overriding the price
Completely overriding the price does not require a calculation using the product's original price. Instead, it involves setting a new price manually or through a predefined value, disregarding the original price entirely. For instance, in Salesforce Industries CPQ, a price override replaces the base price without performing any calculation based on it, making this option incorrect.

Summary:
This question assesses understanding of pricing mechanisms in Salesforce Industries CPQ, specifically how different pricing actions interact with a product’s base price. Discounting inherently involves a calculation using the original price to determine the reduction, while overriding replaces it without computation. Knowing these distinctions is crucial for configuring accurate pricing rules in CPQ for telecom or other industries.

Reference:
Salesforce Industries CPQ Documentation

Explanation:

Root entity context scopes define the primary business object from which a CPQ process is launched. The key scopes are Opportunity (for new sales), Quote (for configuring a proposal), and Contract (for renewals). These entities contain the line items that are evaluated by CPQ logic.

Correct Options:

B. 🎯 Opportunity
The Opportunity is a fundamental root entity context scope. Many CPQ processes, like generating initial quotes and calculating roll-up summaries, are initiated from and operate within the context of an Opportunity, which represents a pending sale.

C. 💰 Quote
The Quote is a primary root entity context scope. Pricing rules, product rules, and calculations are most commonly evaluated within the context of a specific quote, as it is the central document for configuring and proposing a deal.

F. 📝 Contract
A Contract can serve as a root entity, especially for renewal scenarios. When generating a renewal quote, the existing contract provides the context for the products, terms, and pricing that need to be considered.

Incorrect Options:

A. ❌ Order
An Order is not a root entity context scope. It is typically a downstream system of record created after a Quote is accepted. CPQ calculations and rules are not evaluated from the Order context.

D. ❌ Asset
An Asset is not a root entity context scope. While assets are important for renewal processes and can be referenced within a quote line's context, they do not serve as the root starting point for CPQ calculations.

E. ❌ Account
An Account is not a root entity context scope. While account fields can be referenced in rule conditions for targeting or pricing, the CPQ process itself is not initiated from an Account record.

G. ❌ Product
A Product is not a root entity context scope. The Product object contains definitions, but the contextual evaluation of rules and calculations happens on a Quote, Opportunity, or Contract that contains those products as line items.

H. ❌ Order Line Item
An Order Line Item is not a root entity context scope. It is a child of an Order. CPQ logic is applied at the quote level before an order is ever created.

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:

✅ Correct Option: A. Products can be set as non-assetizable
Assetization is the process in Salesforce Industries CPQ where a product or service is converted into a customer asset upon order completion. This allows for a record of what a customer owns, which is essential for future activities like service, support, or order modifications (e.g., upgrades or downgrades). However, not all products need to be tracked as assets. For instance, one-time charges like an "installation fee" or "shipping cost" are not recurring and don't represent a long-term service or good. In Salesforce Industries CPQ, you can flag a product with the "IsNotAssetizable" field to ensure it is not converted into a customer asset after an order is fulfilled.

❌ Incorrect Option: B. Existing customer assets must be marked as assetizable
Existing customer assets are, by definition, already assetized. They have already been converted from an order line item into an asset record. The "assetizable" flag is a product setting that determines whether a product will become an asset in the future, not a property of an asset that has already been created.

❌ Incorrect Option: C. Setting a product as not assetizable ensures that the product is offered as a promotion to customers
The "IsNotAssetizable" flag has no direct connection to promotions. It is a technical field that controls whether a product creates a corresponding asset record upon order fulfillment. Promotions are typically managed using a separate set of features, such as promotions, discounts, or special pricing rules. A product can be non-assetizable and not be a promotion, and a product that is a promotion can be assetizable (e.g., a "promotional subscription").

Summary:
The question focuses on the concept of assetization in Salesforce Industries CPQ, which is the process of creating a record of a customer's purchased products or services. The correct statement identifies that not all products are meant to be tracked as assets, and the platform provides a way to prevent this through a specific configuration setting.

Reference:
Salesforce Help: Assetization and Activation in Industries Order Management

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:

Correct Option ✅: A. createCart method
The createCart method is required to initialize a shopping cart session before products or configurations can be added. Without this method, no cart context exists, making it impossible for Guided Selling to function. It ensures that subsequent operations such as price association and product selection are tied to a valid cart instance.

Correct Option ✅: B. Associating the cart with a valid price list or price book
Every cart must be tied to a valid price list or price book so the system knows which prices to apply for selected products. Guided Selling relies on this association to correctly calculate and display pricing in the cart. Without it, products may appear but won’t have valid pricing data.

Correct Option ✅: C. HTML Template for horizontal or vertical mode
The Guided Selling cart requires a rendering layer that defines how products and categories are displayed. HTML templates in either horizontal or vertical mode provide this structure. They enable a user-friendly, step-by-step selling experience that’s consistent across the cart. Without this, the cart cannot visually present options to the user.

Correct Option ✅: D. Associating the cart with a valid account
A cart must be linked to an account so billing, entitlements, and applicable product offerings can be validated. Guided Selling uses account associations to determine eligibility rules, discounts, and valid configurations. If no account is associated, the cart cannot be processed in a real-world business context.

Incorrect Option ❌: E. Associating the cart with valid user profiles
While user profiles control overall system access, they are not specifically required for building a Guided Selling cart. The cart relies on account and price list associations instead. Linking to user profiles is a broader Salesforce security feature, not a direct Guided Selling configuration step.

Incorrect Option ❌: F. Multiple price lists for filtering product categories
Guided Selling does not require multiple price lists. In fact, a single valid price list per cart is sufficient. Filtering of products and categories happens through rules, attributes, and catalog configuration rather than multiple price lists. Multiple price lists could cause conflicts in pricing logic.

Incorrect Option ❌: G. Linking getCartItems to the template
The getCartItems API is not the required method in Salesforce Industries CPQ; the system uses getBasketDetails for retrieving cart contents. Linking getCartItems would be ineffective since it is not a supported or recognized call. This makes the option invalid for Guided Selling cart construction.

Summary 📝
To build a Guided Selling cart, you must establish a cart session using the createCart method, associate it with both a valid price list and a valid account, and provide an HTML template to control how the selling flow appears. Other options like user profiles, multiple price lists, or unsupported API calls are not necessary. These four requirements create the foundation for a functioning Guided Selling cart in Salesforce Industries CPQ.

Reference 🔗
Salesforce Help: Guided Selling and Cart APIs

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:

Correct Option: 🟢 B. To ensure the cart continues to appear between process steps
Guided Selling in Salesforce Industries CPQ requires a persistent cart to maintain the cart’s state across multiple process steps. This ensures that users can seamlessly navigate through the guided process, adding or modifying products, without losing cart contents between steps. The persistent cart supports a continuous user experience, preserving selections as the user progresses through the OmniScript-driven flow.

Incorrect Option: 🔵 A. To prevent the regular Vlocity Cart from appearing
Guided Selling does not aim to prevent the regular Vlocity Cart from appearing. Instead, it enhances the cart experience by guiding users through a structured process. The persistent cart ensures continuity within Guided Selling, not suppression of the standard cart. The regular cart may still be accessible outside the guided process, making this option incorrect.

Incorrect Option: 🟡 C. To launch the OmniScript from the Vlocity action button and begin the process
While OmniScript powers Guided Selling, the persistent cart’s role is not to launch the OmniScript or initiate the process. The cart maintains product selections across steps, not triggers the process start. The Vlocity action button may invoke the OmniScript, but this is unrelated to the cart’s persistence, which focuses on retaining cart data throughout the process.

Incorrect Option: 🟠 D. To fully display the instructions and step titles for each process step
The persistent cart is unrelated to displaying instructions or step titles in Guided Selling. These are managed by OmniScript’s user interface components, which control the presentation of steps and guidance. The cart’s role is to preserve product selections across steps, not to handle UI elements like instructions or titles, making this option incorrect.

Summary
This question tests understanding of Guided Selling’s functionality in Salesforce Industries CPQ, focusing on the persistent cart’s role. The cart ensures continuity of product selections across multi-step processes, enhancing user experience in telecom or other industry configurations. Misunderstanding its purpose could lead to incorrect assumptions about UI or process initiation, critical for CPQ developers.

Reference
Salesforce Industries CPQ Documentation