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:

- Discounting requires a calculation using the product's original price to determine the new discounted amount
- A 20% discount means multiplying the original price by 0.8 (100% - 20% = 80%)
- Overriding completely replaces the price with a fixed value without any calculation

Key Difference:
- Discounts are percentage-based and relative to the original price
- Overrides are absolute values that replace the original price

Explanation:

In Salesforce Industries CPQ (Vlocity), Context Rules are driven by the concept of a root entity, which defines the context or scope in which rules should apply (such as during quoting, asset-based ordering, or contracting).

These root entity context scopes are the top-level Salesforce objects that serve as the entry point for rule evaluation. These are:

Order
Opportunity
Quote
Asset
Account
Contract

These objects serve as valid scopes when configuring context rules, including Qualification and Evaluation Context Rules. Rules inherit field values from the root context and evaluate conditions accordingly.

Why the Others Are Incorrect:
G. Product ❌ Not a context scope—products are evaluated within the context, but not as a root entity themselves
H. Order Line Item ❌ This is a child of Order—not a root-level entity for context evaluation

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:

In Salesforce Industries (Vlocity), products can be configured with the Assetizable flag:
- When enabled (true), the product creates assets when sold (e.g., devices, service plans)
- When disabled (false), no assets are created (e.g., one-time fees)
- Controlled by the vlocity_cmt__IsAssetizable__c field on Product2

Why Other Options Are Incorrect:
B. Assets don't need marking - this flag applies to products, not existing assets
C. Non-assetizable doesn't mean promotional - promotions use price rules
D. Promotions are managed separately through pricing configurations

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:

To build a Guided Selling cart in Vlocity, you need:

createCart method → Initializes the cart instance.
Price List/Book → Required for product pricing and availability.
HTML Template → Defines the cart's UI layout (horizontal/vertical).
Valid Account → Essential for customer-specific pricing and eligibility.

Why Not the Others?
E. User profiles → Not mandatory (cart rules typically use account/price lists, not profiles).
F. Multiple price lists → Optional for advanced filtering, not core to basic setup.
G. getCartsItems linking → Handles cart rendering, not initial construction.

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:

Guided Selling requires a persistent cart to:

Maintain cart visibility across multiple steps of the selling process.
Allow users to review/modify selections while navigating through different stages (e.g., product selection → configuration → checkout).
Prevent data loss when moving between steps.

Why Not the Other Options?
A. Incorrect → The persistent cart doesn’t "prevent" the regular cart; it enhances it for guided workflows.
C. Incorrect → OmniScript launch is handled by actions, not cart persistence.
D. Incorrect → Step titles/instructions are managed by OmniScript layouts, not the cart.